CIMI MTF Minutes 20140911

CIMI Modeling Taskforce - Meeting Minutes

Thursday 11 September 2014 @ 20:00-22:00 UTC

Attendees

• Stan Huff
• Linda Bird
• Deepak Sharma
• Patrick Langford
• Sarah Ryan
• Daniel Karlsson
• Rob Hausam
• Thomas Beale
• Joey Coyle
• Gerard Freriks
• Patrick Langford
• Harold Solbrig
• Eithne Keelaghan

Draft Agenda

• Proposal for CIMI to become a part of IHTSDO
• Arrangements for the CIMI Modelling Taskforce face-to-face meeting in Oakland
  • Agenda planning
    • Finalize terminology binding and use
      • Finalize the RM representation of coded_text
      • Post coordination in a coded field
    • Finalize specialization patterns
    • General review of current lab contents
      • Style issues
    • Goal: Lab models ready for alpha publication
    • Examples of instance data in the models
    • Ideas for the next set of models
    • Generating FHIR profiles from CIMI models
    • Review AML especially with respect to the representation of example models
  • Terminology Binding Topics (whatever is current), such as:
  • Introducing URIs to Coded Text
  • Defining fixed value and value set bindings in ADL
• Specializing identifiers from CIMI patterns in ADL
• Review of next steps

Detailed Meeting Minutes

Stan: Thanks for being here. I sent out a draft - is it OK? First - a brief update on executive activities on CIMI... becoming a part of IHTSDO. Not a discussion though. Want to do planning about the Oakland meeting... What we want to accomplish. Then terminology binding... Since I missed last meeting, I am not sure where we are at. And other issues on the agenda today?

[No Response]

Stan: OK.

Aligning CIMI with another Organization

Stan: So, a brief report. The executive committee has discussed whether we should join or align CIMI with... organization. We thought the best approach was to align with an existing SDO. And after further consideration... considered CDISC and IHE and openHealth Tools... We came down to.. the 2 best options were IHTSDO or HL7. And the executive committee took some time to visit with Chuck Jaffe... and Don Sweete... In the end, there was a preference by the executive committee to become a part of IHTSDO.

Stan (cont'd): The executive committee has prepared a statement of how that might happen and how the 2 organizations... might become part of IHTSDO. So that written description went to Don Sweete who shared it with IHTSDO... and talked about what resources would be needed... Some of you have been exposed... discussed what we want to use for tooling and how work with others... Has to do with overhead of hosting websites and other overhead. As we get further along... will hold general CIMI membership meeting to give people the chance to describe their points of interest... etc. I welcome comments and questions relative to that initiative. Any thoughts?

Gerard: 13606... We discussed. We think it is a sensible route to explore.

Harold: The timeframe?

Stan: We hope that... don't know if will be finished, but hope progress to report at the fall IHTSDO in Amsterdam... within 6 weeks.

Tom: What does IHTSDO think they will get out of it?

Stan: It would be those folks who could say. My impression is there is a belief that for SNOMED to be... [difficult to hear]they need to define... terminology between... terminology and uniform models. So having... tightly bound to SNOMED would... decrease barriers in clinical systems.

Thomas: Sounds good. That is what I was talking to them about as a committee member 6 years ago.

Stan: Glad you did not say that.

Thomas: I'm sure all here get the irony.

CIMI Modeling Taskforce Face-to-Face Meeting in Oakland

Stan: OK - Meeting in Oakland. Sarah?

Sarah: We have the location. First 2 days (near?) the new Kaiser Hospital. Third day - near the San Francisco Airport. Third day - a tour of Kaiser Hospital. Kaiser will feed all Monday and Tuesday, we will be on our own on Wednesday. Agenda - I will be glad to help, but... But I don't have notes from the meeting in July. Issues to address - unique opportunity to get some work done.

Harold: Where are we as far as getting Patrick's work into a repository? Can we publish an alpha?

Patrick: Anything - what we showed last time... need consensus on terminology bindings. Models are in good shape. Thomas brought up concerns on test model. But I am waiting.

Harold: We can touch on that today... I am comfortable on AOL-side... But I know Linda had questions about terminology-id.

Linda: Last I heard there were a few outstanding issues on models... Not sure if we came to conclusion on Tom's email.

Harold: Has Patrick done face-to-face?

Linda: Face-to-face gives us the opportunity to do it faster. Has there been progress during the week?

Patrick: I have been helping him on Git Repository...

Thomas: I am trying to get Git to work. The ability to retain a node from any level to be overridden on deeper arbitrary level is working now. Have to get into workbench. Worst case - Patrick and I can work together so can get something to see what should look like. But looks good to me. So - you can specialize generic element node from clinical... at any level... So - specialized once or multiple times...

Linda: Great. Solution to (?) in regards to closing off the node?

Thomas: I am going to implement what you and I agreed on.

Linda: Cardinality?

Thomas: If max occurrence is 1, then straight override. If max unbound, then keep original node and... children... I think hard to... I can implement that and get going and make changes to current archetype. I sent an email with screen shots and cloning of parent node. People will have to look at and... clinical meaning.

Stan: In situation where might want an outcome... - can fix?

Thomas: Yes - a way to override. Closing of parent... Then if you end up with that, you can prohibit by... repeat that node... id... and manual removal.

Linda: (?)

Thomas: Not sure I like that.

Linda: A decent short-term or...

Harold: I will need to understand the ramifications of that in response to AML /AOL because it may violate one of our rules.

Gerard: Thinking about it - will be quite complex... The way our model thinks is a different way... When specialize, change the... of node. Makes specialization easier, I think... Just wanted you to know this.

Action Item - Gerard

Thomas: With respect to your suggestion, I read your email. You need some examples - put them in the repository so we can look at with the tool.

Harold: Can you put something up now?

Gerard: I must look for it... Create examples.

Stan: OK. So, coming back to the agenda for Oakland. I think you can see the screen. Finalize term-binding. Other modeling style issues - so when we look with real content, we can look at discussions. Probably have to do with pre/post coordination. Will be those to talk about. So - style issues...

Linda: I would be impressed if we get terminology binding done before the meeting. Would be good if by the end of the meeting we have lab models ready for alpha publication. Sarah - do we have teleconference facilities?

Sarah: I can...

Stan: And I have voice over-speaker thing...

Sarah: So - the answer is yes.

Stan: So - have the lab models ready for alpha publication. If we run out of other things to do, I would like to discuss how we make examples of instance data in the models, because that is one thing that makes implementations of the model useful...

Linda: And think about proposals.

Stan: InterMountainHealth is working on the creation of FHIR profiles from the models. Don’t know if we want to talk about this at the meeting.

Linda: Worth keeping in mind.

Stan: It has value. Would like to get the group's insight... A lot of issues that come up about FHIR profiles will come up... XML schema... issues about naming and aliases... general issues... Would be useful to discuss...

Thomas: I have most of FHIR in a Reference model... I spoke with Graham... It is interesting to look at in the Ref Model in the tool.

Stan: Terminology-binding issues... How do we signify how to constrain a coded_text field to... a set of coded_text elements in field?

Harold: Not talking about post-coordinated?

Stan: No - composition in a ... field.

Harold: I know we discussed in terms of term-binding... We decided we would postpone until we got one taken care of.

Stan: Maybe we won't want to talk about yet...

Linda: Might want to re-visit.

Harold: OK. Term-binding... I think we have it down to a single... But when open to multiple...

Stan: Other?

Harold: Need to review AML - the way the example models will be represented... To be sure our interpretation matches others...

Linda: Finalize the coded_text. Make sure the Ref Model is finalized.

Stan: Coded_text or ...?

Linda: Coded_text.

Stan: OK.

Specializing identifiers from CIMI patterns in ADL

Harold: Last time - I set out to produce a 2.0.2 trial model which I did. It is in the Repository. I sent out an email. [Harold shows on the Screen]

Harold: So - Ref Model Release 2.0.2. The HTML - up from a server. Pick up the pdf... simplest. So I have been asked to propose 2 things.

Harold (cont'd): The first thing we talked about - How to identify things that aren’t constrained and should be constrained... is_im... infrastructure and is_im.... And I added is_ADL_primitive type. If you find it on one of these types down here, there is a... And... ADL-date-time... How you have described... So I put those in on duration-date-time... date-time. So, you use the... accuracy... value status.

Harold (cont'd): Most important on terminology constraint. Don't constrain anything here... Take the... of the constraint and... The second bit... on coded_text... We removed term_id. In SNOMED - they said you should not expose those. And we added URI... optional string. And I proposed a change to the documentation... So add URI.

[Harold shows last week's email from Linda]

Linda's email of Sept 4, 2014

---

Here is a summary of the action items I recorded from today's modelling taskforce meeting:

1. Reference Model
   • Update CODED_TEXT datatype in UML and resulting BMM
     • Add uri: String attribute (cardinality [0..1] ??)
       • Reasoning: To allow uris to be used to refer to a coded concept in code systems that supports uris.
     • Delete term_id: String attribute
       • Reasoning: This will never be constrained in a CIMI archetype, and will not appear in our example instances. If an implementation requires this, they can add this attribute to the implementation datatype.
   • Distinguish the attributes which will never be archetyped, but are still required for example instances (i.e. "is_im_runtime" attributes)
   • Harold? to update UML with the above, generate a new BMM file and place into GitHub repository.
   • All to ensure that their ADL Workbench is using the reference model from the Github repository.
2. Terminology Binding
   • Fixed value set constraints: To set value for uri, code, terminology_id and term
   • Value set constraints: To link ac_code with uri for value set
3. ADL workbench
   • Tom to check how the workbench handles node specialisation - to ensure that a repeatable node that has been specialised once is still available to specialise again in a deeper model specialisation.
   • Patrick to update node ids when this is working

---

Harold: We need to either manually edit the... or ask Michael to turn the crank or us.

Action Item: Harold to contact Michael

Linda: Contact Michael...

Harold: OK. When talking about Ref to Terminology-code, you have the URI = definitive reference. We have been trying to come up with terminology of terminologies. Might use... or... A lot better off with URI's than terminology... So we all agree. So - take a URI - can split into namespace and code...

[Harold shows his email]

Harold's email of Sept 8, 2014

---

Folks,

Terminology proposal:

We have URIs (e.g. http://snomed.info/id/74400008, http://loinc.org/id/12345-1) These can also be represented as a namespace/name tuples (e.g. SCT:74400008, LOINC:12345-1).

These, in turn, can be described in one or more terminologies (coding systems). SCT:74400008 might be described in SNOMED CT International or SNOMED CT US Extension. LOINC:12345-1 might be described in the LOINC terminology -or– (significantly) in SNOMED CT International.

The important thing to note is that, while there is typically a correlation between the namespace and the describing code system, this is not always the case.

Ignoring, for the moment, the notion of “code phrase”, the following attributes are potential candidates for our instance data

uri— a URI that identifies the entity (class, category, concept) being referenced in the data instance. Namespace/code – a namespace identifier/ code tuple that identifies the entity (class, category, concept) being referenced in the data instance

terminology_uri – a URI that identifies the terminology that contained the description of the referenced entity

terminology_name – a human readable name of the terminology

terminology_version_uri – a URI that identifies the particular version of the terminology that was used for the description

Terminology_version_name – the version identifier

Term – a human readable string that provides a hint to the meaning of the uri/code

———— What is required and what is optional depends, in part, on context.

If we have a data element that is defined in the form: A code that represents an <category> drawn from terminology <T> (e.g. A language code drawn from ISO-3166-1), then the only required field is code.

If, instead, we have a data element defined in the form: A code that represents a <category> (e.g. A code representing a diagnosis), I would argue that the uri should be the required field. The reason for this is that, while folks have tried to standardize namespaces over the years, they have not been successful. Depending on where you look, SCT, SNOMED_CT, SNM, SNOMED, … are all used to designate SNOMED. While it makes sense to have a namespace/code tuple, the namespace portion scopes the code within the context of the application, and cannot be counted on to scope it globally. (FHIR has mandated a set of identifiers, but the scope of these is strictly FHIR — the NLM has a whole different set, as does HL7 and various OWL communities).

So – namespace/code is danged handy, but it can’t be used in place of the URI.

The 4 terminology attributes are definitely overkill, and I think that we need to examine the use cases to see whether we really need any of them at the data element level.

Their purpose is to identify the particular description that was used when determining that the supplied code was correct. How will this information be used?

1. To allow someone who is questioning the veracity of the data record to determine what information the author had available to them at the time it was recorded? If so, we need to record a short identifier (e.g. SCT_INTL or SCT_INTL_20140731) that would be sufficiently precise that a human being would know where to look.
2. To allow software to display exactly what the author saw when the information was recorded? If so, we need to record the URI of the version. (I don’t see any use for the URI of just the terminology)

I realize that HL7 has specified an incredibly detailed CD “data type”. With the exception of the code and OID (which is the HL7 equivalent of namespace), the remainder of this data type primarily serves the role of keeping software developers busy and network lines and disk drives full.

————— Proposal:

The CODED_TEXT data type should have:

uri : String [0..1] — “A URI that uniquely identifies the referenced concept. Examples: http://snomed.info/id/74400008, http://loinc.org/id/2951-2, http://id.loc.gov/vocabulary/iso639-1/de"

terminology_id: String[0..1] — "A locally unique identifier for the namespace from which code was derived. Examples: SNOMED_CT, LOINC, ISO639-1”

code: String [1..1] — “A code that uniquely identifies the referenced concept within the context of terminology_id. Examples: 74400008, 2951-2, de”

terminology_version : String[0..1] — “The URI of a terminology or terminology version from which the meaning of the code was determined for the purposes of this record. Examples: http://snomed.info/sct/900000000000207008, http://snomed.info/sct/900000000000207008/version/20130731, http://loinc.org/, http://loinc.org/246, http://id.loc.gov/vocabulary//iso639-1”

term: String[0..1] — “A human readable string that conveys the intended meaning of the code. Examples: ‘Appendicitis', 'Appendicitis (Finding)’, 'inflamación aguda del apéndice’, 'Serum Sodium', 'Plasma Serum Sodium’, ‘German’, ‘Deutsh’"

Documentation for CODED_TEXT itself:

A reference to a class, category or individual that is described in an external terminology. Every CODED_TEXT instance must either have a uri, a code or both. When a uri is present in a CODED_TEXT instance, it will be treated as the instance identity — any two CODED_TEXT instances reference the same concept if they have the same uri, and the remaining fields will be ignored. If a uri is not included in a CODED_TEXT instance, the instance identity is the terminology_id / code pair. Any two CODED_TEXT instances reference the same concept if they (a) both have no uri and (b) have the terminology_id and codes. The terminology_version and term attributes are strictly informative and play no role in determining the concept referent.

---

With respect to the is_im_runtime attribute:

While the current model doesn’t have a formal stereotype, it does use colors to identify the purposes of various classes. In particular, blue represents “Datatype” and pink, “PrimitiveTypes”.

Of the primitive types, ADL/AML can directly constrain: Boolean, Real, Integer and String. The Byte, Character and URI types cannot be constrained because they don’t have a corresponding ADL/AML type.

Of the “data types”, ADL/AML can directly constrain “DATE_TIME, DATE, TIME and DURATION and CODED_TEXT"

To indicate this, I added a new EA stereotype “is_adl_primitivetype”, which can be set on primitiveTypes, dataTypes or classes and which indicates that the internal structure of the class (if any) must be constrained through the ADL primitive type constraint mechanisms and the corresponding mapping to the type itself.

Will get the model posted and published today…

Harold

---

Harold: There is an important distinction between SCT:7400008... More than one terminology may say things about this. SNOMED CT... SNOMED extensions, other terminologies. So, there is an important distinction... Tends to be SNOMED CT International that talks about SNOMED CT terminology, but not always... So tend to be the... namespace... I listed the URI, namespace and code - tuple, which is the terminology here... This is the official URI of SNOMED CT International... a 9 followed by zeros followed by 207008... The name... Have to agree on what we mean by... At some point we need to get with Regenstrief and get this figured out.

Action Item - Meet with Regenstrief - Stan and Harold

Stan: Should we get that on the next public LOINC meeting, or by email... talking to Clem and Dave and me?

Harold: I don't know.

Stan: Probably you and I and Dan and Clem can talk.

Harold: FHIR is starting to propose URI's for this thing, too... We have to... Never total consensus. But the fewer candidates we have, the better. So finally - human readable. Last week - the term in there... Hard to read without knowledge of what code references... I think the point is... Where it makes sense... Some term that gives the reader a clue to what is going on. Equivalent of... go through ADL... just comments... But without these hints...

Linda: Other - the text in vertical bars without identifier in compositional grammar.

Harold: Yes - the moment you say must be a fully specified... than how say in LOINC... Those are the bits that are there. So I am proposing the CODED_TEXT model that is here... So I am proposing URI... that... the context... Delightful that Library of Congress has gotten into linked... Will never get URI from ISO... So anyhow - identify the Ref... We had the terminology URI... and the terminology ID.

Harold: I proposed the namespace from where code was derived... could be a URI. Not SNOMED CT International... Says this is a concept code that is unique in SNOMED CT... I propose we have a code that uniquely identifies the reference concept...

Harold: "The CODED_TEXT" data type should have...

Harold: A human-readable string that conveys the intended meaning of the code...

Linda: My memory of model is... every CODED_TEXT instance must either have a...

Harold: One of the outliers is the language code. If we have a community agreement... is overkill... My intent was to allow this aspect to...

Linda: Term_id was mandatory in the picture.

Harold: OK. If we have 2 data instances... They both have the same URI, do they reference the same...? I argue Yes, but am open to advice and corrections. So there is the proposal. Linda asked... Intent is scoping namespace for this code is SNOMED CT.

Linda: I was saying... I though it useful... If we aligned that terminology with...

Harold: I don't think FHIR differentiates between... We don't have to put the namespace, but it's nice to put the code.

Stan: I am not catching the difference.

Harold: For example, the food ontology and wine ontology... The wine out imports the food out and says a bunch more about... So says... But the description we are looking at is food potable liquid in wine ontology... So, we know potable liquid defined in food ontology as opposed to... So conventionally... used to prefix for... A classic example would be if we defined in CIMI... We still use SNOMED namespace... Is SNOMED concept, but won't find a description in SNOMED International, but need to go to...

Stan: OK.

Harold: Other - might have a different description for... And we could use 74400008... Difference between CIMI namespace and who says something about it...

Stan: Questions about this?

Linda: I have no problems with having... space... should maybe be... in archetype... IHTSDO... should be globally... That is why I prefer the...

Harold: the only way globally unique is URI. The id... ends up more along the line of the term itself. We could agree that SNOMED CT will always be the prefix. It gets to be a bit of a challenge... If have data needs with SNOMED CT in these, it is a bit more brittle.

Thomas: That dial-up box. Those settings... So the left hand key... SNOMED CT... is going to watch outer tag in term bindings. So, is it the community or... Has never been resolved... URI on right-hand-side... the model template for the URI's... Would be good to get these left-hand names agreed... That is the system I have now.

Harold: Is ideal... These identifiers... There is no single deterministic rule that allows you to differentiate the namespace from the code. So I think this is perfect. So URI - turn into terminology and code, I say. Trying to replicate a pattern in XML... Up front you identify a prefix... and concatenate that prefix onto the code.

Linda: But term... would not have...

Harold: If we made... instead of SNOMED CT, we would have created data records with SNOMED CT in its place... The URI becomes the one definitive identifier... We would not put prefix here... I wonder whether we should not replicate it over here, too.

Linda: Depends on if we want a local namespace. But I think SNOMED id... follow IHTSDO...

Harold: Trailing slash or not...

Linda: Official IHTSDO...

Thomas: I would be inclined to take notice of what FHIR and others would do... If data flying all over the place and... If one bunch doing... and the other...

Linda: Yes - I agree.

Harold: Yes. You can say FHIR will constitute a good chunk of data floating around. A few years ago - HL7 and LMN (NLM?)- could not get them to agree.

Linda: Harold - maybe useful to share...

Harold: OK.

[Harold brings up the FHIR website]

Linda: Talk about preference for URI...

Harold: Glad to see that they have LOINC. I think should use WHO URI's and not FHIR URI's.

Thomas: Should not use URI's that have mechanical aspect inside URI...

Harold: Yes - we need to be advised by this...

Linda: If follow that and SNOMED CT...

Harold: So - they have without the trailing thing... So instead of SNOMED CT... if we can use FHIR. Can we reference the site...

Linda: Have to be careful about FHIR... norms... WHO...

Harold: IF SNOMED owns the prefix... if it references this, should get confirmation from IHTSDO server that this is canonical URI.

Linda: Or talk to Graham and ask him to change WHO URI's.

Harold: So - off the WHO website. I happen to know who owns this... OK. So - how about this terminology version thing? 4 fields... The URI for particular code-system... The name... The URI for version and name for version... If... into one field... is it too much? All codes of this form... intended to be... Down the line... What information did you have... What went wrong and why... So I left loose... but could make more of it.

Linda: Other option - including terminology versions. URI... and id... and name to make it readable... From IHTSDO perspective... URI... But having a name would be...

Harold: Interesting. The question I have is... Don't know if people feel...

Linda: Australia and Singapore care about the version because need to distinguish between them.

Harold: 2010 vs 2008 appendicitis?

Linda: No - agree that identity of concept code... id... is independent of version, but...

Harold: Importance is URI... How will be used by someone questioning the... If strictly software validation, we probably want to lock down the version.

Linda: Yes - the minimum...

Harold: The intent would be... ADL could require a version. We could demand a version be present.

Linda: Is term-id mandatory?

Harold: Yes. I need to forward [what is on the screen] before I can edit...

Linda: Yes.

Harold: OK.

Linda: Might want to put "where available"... Favor URI's if they are there...

Harold: We could say if going to use the terminology, has to have URI.

Thomas: Yes - by imperial fear.

Harold: If we are going to use it, it has to have a URI.

Thomas: FHIR has to be more forgiving... because of existing... or will create problems...

Linda: I agree. The question is if we will ever use a terminology that does not have a URI.

Thomas: What FHIR deals with... terminologies... whether ever had a URI... Data through FHIR... If we are talking about terminology without a URI, there is probably a bigger problem...

Harold: Have to decide what version looks like in LOINC. OK - there is the proposed... Not talk about runtime. So I will kick that out to everyone.

How will post-coordinated be handled?

Linda: So - how will post-coordinated be handled?

Harold: Yes. We were going to add a type that carried notion of post-coordinated expression. The reason I bristled here, hard to distinguish Use-case with... Is gnarly... So I wanted to extend this or have another type where... Going to identify grammar and version of grammar with version over time...

CODED_PHRASE

Stan: We made entirely new type... Coded phrase rather than coded-type.

Harold: So if hit a coded-phrase I could say what grammar did they use? So I could parse... So are we going to be building post-coordinated expressions...

Stan: I don't think we will get to this until Oakland. But models... till now... just used single codes...

Linda: I am happy with that suggestion... and to postpone.

Thomas: If you make a special type for coded_phrase, would have to...

Harold: Not sure you would want to descend it... The phrase still requires additional recognition depending on phrase. The one thing we want to avoid... I have seen at Mayo... people putting together quasi... So what does it mean with 2 together? Depends upon which 2 they are. Want to do in a consistent fashion.

Linda: We don't need to come to a solution now, but... in archetypes... CODED_TEXT - simple and others subtype CODED_TEXT_PHRASE - has a code expression and language version.

Harold: Could try to build a URI for a phrase.

Stan: Glad we brought it up so all could be thinking about it.

Action Item - Harold

Harold: So as a task for tomorrow... I am going to create... Identify... changes in the documentation in this and put out in same GitHub Repository... And will have to find out if Michael can do BMM... Thomas - you mentioned end of July for Release of stable (4.5??) Did you do this?

Thomas: The only change is changing to the flattening rule.

Harold: Because terminology constraint grammar... is ADL primitive type... When presented with appropriate AOM.

Thomas: The workbench does that... If you go into menu in workbench and pick a profile... Terminology_code is an AOM built type... So that is mapping a term-code to CODED_TEXT. So if you look at...

Thomas: Now if you wanted to put another one of those entries for...

Harold: Is an inbuilt data type...?

Thomas: No - data-type. You put flags on data-type. Just so you know.

Harold: I ended up...

Thomas: One of the reasons why I did that because it allowed me to map the differently named properties. Whereas in BMM... harder to do.

Harold: Key is if required term-versions as URI, the only way is if required in term-type.

Thomas: So...

Harold: So in AML - when pull in Reference-model... This is stereotype... treated as a unit... Has a tag... pick up the one Term-code... Should be a type in AML... So, for example, AML is date-time... And is the job of someone applying this... to define the set of rules. So that is all I have to say.

Stan: Nice work. I am still absorbing.

Harold: Should go over in San Francisco.

Action Items: Groundwork for face-to-face in Oakland

Linda: Other is to consider what is realistic to achieve. Can get new version of BMM. Thomas get new workbench out. Patrick could get the id's so models were accurate. If groundwork were done before meeting, would be more efficient. Stan: So have 15 minutes left. Any more about specialization patterns, Thomas?

Thomas: Not from my point-of-view, except people can't see it fixed.

Stan: Would it be useful if you would not mind working us through the email.

Harold: Yes - I have not read them.

Thomas review his email to MTF

Thomas: OK. The problem was, if you take the example... Essentially, some of these child notes should be able to be children of id 0.4. If you had done that in the current way, those children would have replaced the id 0.4 - would have gone away. If down deep in background_stain_present, might want another child. Would not do that since had disappeared. But now... Does that make sense?

Stan: Yes.

Thomas: So - new flattening rule, if had been children of id 0.4, would still be there. And I could make children 6 deep.

Harold: What would identifier look like? 0.4.0...

Thomas: Yes. Id 4.0000 and some number. So I am using id 4 as an example. But what about node-like... name. Let's assume name should be... If you wanted to specialize priority, that specialization would replace priority... child 0006... Would not have 0006... Specializing something that can only exist once.

Patrick: I have not pushed those changes yet since they were broken.

Thomas: I am racing to have solid version of workbench... running... Can now do an install... Reference per repository... Goes to GitHub... knows the URI's... Can do commands... So is populated from the repository. The names of everything are now files in the repository... So - can just add a repository... Git_repo... If you go into the CIMI-Repository, you will see... Those files are there... libraries.

Stan: So - all done. Any more questions about specialization-style... whether you retain the parent?

Thomas: I think... will become apparent.

Linda: We also talked about abbreviated way...

Action Item: Harold to contact Michael

Stan: So - to try and meet the goal of having accurate binding for the Oakland meeting, you will contact Michael, Harold?

Harold: Yes.

Stan: And let Patrick and Thomas and... know

Stan: OK - thank you. I like the direction this is going. It's very gratifying. OK - stand adjourned.

[end-of-meeting]