Identifier needed to refer to a specific release of FIBO

[ghost]

At present, the only way I can determine the identify of a specific release of FIBO is a SPARQL query of the
form: select * where { ?module owl:versionIRI ?version }. It would be helpful to have a single identifier that occurs as metadata and, possibly, in the file names of the serializations. One way this could be accomplished is via the use of the provenance ontology.
By creating a separate named graph to hold provenance information and in that graph:

1. Create triples of the form {versionIRI as presently constructed} rdf:type prov:Entity with prov:wasDerivedFrom identifying the previous version
2. Create a prov:Bundle with its own unique versionIRI as the IRI for the bundle along with prov:wasDerivedFrom triples that list subject versionIRIs created in the previous step

[ElisaKendall]

Hi Kevin,

Are you looking for this in the github versions or the version published in the quarterly release, where every ontology has the same version tag? We do tag the release in github (Dean just did that for Q3, in fact), although that doesn't manifest itself in the ontologies at all.

I think it would be reasonable to add something in the published versions as another step in the publication process, but tracking it in the in-flight github versions might be more challenging. For those I tend to use the OMG yearmmnn approach in the version IRI, as each ontology might evolve independently of the others.

[VladimirAlexiev]

@ElisaKendall where is this "same version tag"?

I've looked at FIBO-2020-03-dev\latest\BE\FunctionalEntities:

• FunctionalEntities.ttl has
  • owl:versionIRI <https://spec.edmcouncil.org/fibo/ontology/master/latest/BE/FunctionalEntities/FunctionalEntities/> which doesn't carry any date or version tag
  • a detailed skos:changeNote that emphasizes the problem (all changes mention the same version?!) :

		"The https://spec.edmcouncil.org/fibo/ontology/BE/FunctionalEntities/FunctionalEntities.rdf version of this ontology was modified by the FIBO 2.0 revision to address missing labels and definitions on the deprecated sole proprietorship class to match those in the equivalent class." ,
		"The https://spec.edmcouncil.org/fibo/ontology/BE/FunctionalEntities/FunctionalEntities.rdf version of this ontology was modified per the issue resolutions identified in the FIBO BE 1.0 FTF report." ,
		"The https://spec.edmcouncil.org/fibo/ontology/BE/FunctionalEntities/FunctionalEntities.rdf version of this ontology was modified per the issue resolutions identified in the FIBO BE 1.1 RTF report. Changes include deprecation of the SoleProprietorship class and making it equivalent to the class with the same name in the Sole Proprietorships ontology. This version also introduces a new FunctionalEntity class, as the parent of FunctionalBusinessEntity in this ontology and as the parent of Government in the GovernmentEntities ontology." ,
		"The https://spec.edmcouncil.org/fibo/ontology/BE/FunctionalEntities/FunctionalEntities.rdf version of this ontology was modified to eliminate deprecated elements." ,
		"The https://spec.edmcouncil.org/fibo/ontology/BE/FunctionalEntities/FunctionalEntities.rdf version of this ontology was modified to eliminate duplication of concepts in LCC." ,
		"The https://spec.edmcouncil.org/fibo/ontology/BE/FunctionalEntities/FunctionalEntities.rdf version of this ontology was modified to generalize certain unions where they were no longer required and eliminate an unused import."

• MetadataBEFunctionalEntities.ttl has:
  • dct:issued "2018-08-27T18:00:00" but that pertains to <MetadataBEFunctionalEntities/> not <FunctionalEntities/>
  • owl:versionIRI that again doesn't carry a version tag or date

So the situation is even worse than what @kptyson describes. All that metadata, but no version tags.

In contrast, all w3c specs carry two things, eg

• This version: http://www.w3.org/TR/2012/REC-r2rml-20120927/
• Latest version: http://www.w3.org/TR/r2rml/

So Kevin, for now you'll just have to state "manually: FIBO-2020-03-dev version or whichever quarterly release you used.

[rivettp]

@dallemang we have a ticket for creating a manifest as part of the publication process - which is where this info belongs IMO. That also allows people to know the date/time and hence what fixes/Pull requests have been included. Any progress on that?
@kptyson in the meantime we already generate https://spec.edmcouncil.org/fibo/ontology/MetadataFIBO/ in file MetadataFIBO.rdf which does have a owl:versionIRI for production releases.

[ElisaKendall]

@VladimirAlexiev - you're right - I had forgotten that the work I do to track "something' akin to a version in github in the ontologies using the versionIRI is never published. Only the github versions retain that. So even if I go to the trouble of putting a version in every ontology we revise in github, it never sees the light of day. Those change notes refer to the github version IRIs, FYI.

[dallemang]

@rivettp I thought we had such an issue, but I wasn't able to find it. If you can find it, please paste a link here.
I'd like to tag @przemekgradzki to see if he can put this on his queue; it should be pretty easy to do, and he is a lot faster at turning these things out than I am.
Tagging @trypuz as well, since I think he's the one who sets @przemekgradzki 's priorities.

[rivettp]

Here it is, in Jira https://jira.edmcouncil.org/browse/INFRA-264

[przemekgradzki]

@dallemang @rivettp @trypuz please see comment to INFRA-264

[ghost]

Thank you all for the information you shared.
What I’m looking for is not so much a tagging issue as an architecture issue. I want to be able to determine the version of FIBO that a RDF graph purports to contain by examining the contents of the graph. To achieve this there has to exist a well-known resource that specifies the version of the contents of the graph.

The first difficulty is that the FIBO ontology is published both as multiple graphs and as a single graph, while the vocabulary is only published as a single graph. As a result, any solution will have to be composable. At one extreme of composability is a naïve application of the qualified relations pattern whereby every triple gets annotated with FIBO version identity. Only slightly less insane would be using reification to achieve a similar end. Both would substantially increase the number of triples it takes to express FIBO. At the other end of the spectrum is a manifest as @rivettp commented. That would satisfy my needs if it:
• Is in RDF
• Can be used to unambiguously reference triples in single default graph or multiple named graph modes for every triple in the release