Date

for JG: on the procedure, has worked on the artifact ontology, Turtle side. Cannot make a branch, can only make changes to JG's branch. Expect to be able to make changes in his own branch. What is the procedure? Don't know why unable to make branch for the RDF Toolkit repository. So rights for that repository are not right. Does not have the "create a new branch" option. Did not try to create it locally.

JG: uses GitKraken for this. Free tool. Can use to create new branches. Can also do that in SourceTree. EAL: just created a new branch.

On the ontology, EAL needs guidance using this, needs to go through with JG.

MB: Sub-domains and modules. Module or Sub-Domain?

MB and DA remembers Module. Everyone else remembers Sub-domain for the same meeting.

DW recalls that we were using Module for OMG work but sub-domain in EDM Council terminology.

EAL proposes we use an object property to refer to sub domains.

DECISION: Deprecate Module, use sub-Domain. Elie's object property idea refers to those.

Need to update the relevant document.

EAL question: do we define an "Ontology Product" in terms of artifacts or in terms of domains and sub domains and link each artifact to a corresponding sub domain.

What is an Artifact here? Artifact is everything (every file) that we publish on

https://spec.edmcouncil.org

There are distinctly, source artifacts and destination artifacts. So outputs from the Builder are Artifacts. So these are just the things we publish on https://spec.edmcouncil.org

Thus: Sources are the ones going into the builder and Artifacts are the ones we publish.

Q is how we get from a product to an artifact? We have 4 products. Ontology is one. So what does "ontology product" mean? This means the core of FIBO itself. In the list, where there is "Product - ontology" whether we should define the domains and sub domains in here. Domains and sub domains talk to the source not just the artifacts. So the ontologies are organized into several sub domains and domains. When we produce a Product, it may or may not reflect that structure e.g. FIBO-V does not reflect the structure whereas, FIBO itself does. Some others do and some don't. So, the Domain structure is about the source not about the artifacts.

JG at the product family level (FIBO) we should have a Domain taxonomy pointing to the root, and to the sub domains etc. So, the Domain taxonomy is independent of the products, it is part of the source. Each product can link back to the various domains that is supports. So, a given product may support one or more domains.

DA: in the filter that creates these things, when I am publishing FIBO-V "Which domains are considered done?" - Need to identify that when we publish a given product e.g. FIBO-V.

Then for FIBO itself we have 2 "products" - one is the 6 Pink domains, whereas the other is the 6 Pink + the other 8 or so DirtyPink, so that FIBO-Master has 2 Products with the Product line (for want of a better word) or Product Type, in "FIBO"

We need to model that somewhere so we can say when e.g. DER moves from DirtyPink to Pink.

JG: The Artifact ontology individuals file that the Builder uses - this is stored in each branch so in Pink you will have a different Artifact ontology than for another color. DA if this is so, then there is no artifact ontology that knows what is where in Git. So for instances per David's proposal to excise one Domain in the overall thing - so there would be a 3rd FIBO in the ontology product line, one with all, one with only Pink and one with Pink plus selected items from DirtyPink but not all (e.g. exclude MD in David proposal). So we would need a version of the Artifact ontology that sits outside of GitHub and tells us what we are managing.

JG: You can query GitHub itself. DA: but that will not tell you the justification for each branch. so you could have a file in that branch that you download to tell you that. JG also need an overall something so we can download all the branches we have.

DA more comfortable to have something that can be queried rather than by navigating Git. EAL: Do you mean the colored branches or all GitHub branches? DA Referring to all branches in the EDM Council repository not ur own forks, which are where the smaller branches for JIRA issues live. So in the main EDMC repo, the branches correspond to the statuses we are using to publish, currently Pink, etc. or whatever we end up calling them.

Also Yellow - is one we will never publish, but is in GitHUb. It is our gateway for publishing to OMG.

JG these are different states. Everything in Git will be published in spec.edmcouncil.org.

DW: No, Yellow has OMG URIs in it so it is not published to http://spec.edmcouncil.org

DW: Yellow is ephemeral - has been it he past and may in the future but it doesn’t exist now.

DA but having ephemeral branches has its own overhead. JG if you put all that yellow in the Artifact model then that cannot be stored in Git. Would prefer to avoid that.

DW suppose there was never a relationship with OGM but in future they decide to take our quarterly publication and take that and publish it.

DA then we would delete Yellow from our process. Instead, any OMG Submission team would take what was on https://spec.edmcouncil.org DA we also don't have a clear distinction between what we publish and what we develop. Then we can publish in RDF/XML but publish in whatever we please e.g. Turtle. Then OMG sits at the end of a tunnel waiting for us to send them things.

Does JG agree? Yes. Can upload an RDF Config file into some Yellow branch saying what the status of something is e.g. ignore this, or only publish it on EDM Council or not have FYN URLs. Can do a strip down version of RDF Toolkit that says to ignore or not publish

EAL - this is enough to work with for now.

OK: About file action - can pick that up.

OK: Publication - is able to publish RDF through the process. Done but for the EDW will want to iterate that a bit in terms of the output. Can see the first iteration on Thursday.

DA action 4: SKOSify... DA this is a separate topic. Omar is looking at the construction of About files; Skosify is for FIBO-V. What’s needed for About Skosify isn't the same thing. OK and DA met on this. Done.

Also for OK: when this came up in FLT, PR and EK mentioned the existing OMG SpecificationMetadata ontologies.

SM is in the OMG AB namespace (it is also in CCM), and covers specification level metadata, including Family, Specification (our Domain) and sub-domain metadata. This was the item "Look at OMG metamodel"

DW much of yesterday's discussion centered around keeping FIBO Master, Pink and Dirty Pink aligned. Also what to do before making Turtle files. DA: sent email to TC and JG outlining the issue.We need TC input on this, can do Thursday.

The specific issue is that per the diagram with the drums, Pink is a sub set of Master. Master also has Extensions and DirtyPink. If someone makes an update to Pink that's easy; there needs to be a corresponding change in the isomorphic sub-set in Master. Needs some automation. At present, Pink has moved forward but this has not been brought forward into Master. Things like the https change needs to be done. To be discussed Thursday - please read and prepare.

This is a status per domain per branch? No, that's a separate problem. Here, we are talking about what happens as changes happen in Pink. they are separate branches. I you make an update to Pink we need the same change in FIBO-Master, which has e.g. different http styles and so on. So a straight Git merge won't do it, we need it mechanized.

DW: Want the FCTs working in FIBO-Master, which contains Pink so when they make changes in FIBO Master this would automatically be in Pink. DA this is different to current process. JG can we rename branch to just 'master' in lowercase? Would only make sense if what we use FIBO-Master for is exactly what GitHub expects 'master' to be used at - then and only then can we use the word 'master'

Decisions:

Deprecate the word Module, use sub-Domain. Elie's object property idea refers to those.

Action items

Anthony Coates

Go to Candidate Hygiene Policies "MU proposal that someone goes through the large 'dumpster' of possible hygiene tests and pulls out the ones we would choose to use. Also MB notes that some of the ones in the Ontology Summit Hackathon table are ones with numerical choices to be made, not simply yes or no. This was also assigned to Tony Coates at some point. This will help us get the process down for doing this stuff. But first we need the initial filter of what are the hygiene tests that everyone agrees to. Then have a process that everyone needs to go through as part of something like a Build process that fails each time we break any of the rules."
Dean Allemang Make FIBO Master work in Protege.
Elie Abi-Lahoud (Unlicensed) Deprecate Module, use sub-Domain. Elie's object property idea refers to those. Update the relevant document.
Dean Allemang DA Presentation for Tony and Jacobus about keeping FIBO Master and Pink aligned.
Dean Allemang Omar Khan (Unlicensed) DA has triples saying "This is Pink, this is DirtyPink this is Extension". What to do before making .ttl
jacobus.geluk@gmail.com [X] Omar Khan (Unlicensed) Look at OMG meta model
Dean Allemang Populate first version of About File

Browser not supported