Hello I strongly support unversionned URIs. Versionned URIs will be hell to maintain, to explain, to consume. It is the _dataset_ (in the sense of DCAT) that should be versionned at each release, not the URIs declared inside it. It was mentionned in the original message that *"When one builds a knowledge base (RDF dataset) using cidoc-crm, he/she considers a particular version of the model. "* I think the use-case of upgrading the version of the CRM inside a system originally built with a previous version should also be considered, and in that perspective, having stable URIs is necessary.
FWIW, in a different context (SKOS Concepts), but similar problematics (versionning) I had developped a timeline views in concept pages, allowing to see in which version the concept was introduced, in which version it was deprecated, and enabling a user to switch between the version to display the concept in any version of the vocabulary. See : - Here for a random concept still in force : https://www.reseau-canope.fr/scolomfr/data/scolomfr-7-0/fr/page/?uri=http%3A%2F%2Fdata.education.fr%2Fvoc%2Fscolomfr%2Fconcept%2Fscolomfr-voc-015-num-1201 - Here for a deprecated concept : https://www.reseau-canope.fr/scolomfr/data/scolomfr-7-0/fr/page/scolomfr-voc-045-num-001 (marked with owl:deprecated + dct:isReplacedBy) Cheers Thomas Le lun. 27 sept. 2021 à 16:10, Pavlos Fafalios via Crm-sig < [email protected]> a écrit : > Dear Robert, > > Thank you for your reply (and the interesting pointer to the FOAF's > experience with URIs :) > > I fully agree. It seems that Option B1 (*"always use an unversioned base > URI in all RDFS versions"*) is the better way to go. > > Let's see if there are other opinions on this. > > Best regards, > Pavlos > > On Mon, Sep 27, 2021 at 4:33 PM Robert Sanderson <[email protected]> > wrote: > >> >> Reordering to most important first.. >> >> >>> *(C) BASE URI (NAMESPACE) FOR CLASSES AND PROPERTIES *What base URI >>> should we use for the classes and properties of each version when serving >>> RDF content? There are three options: >>> *Option B1*. Always use an unversioned base URI, i.e., >>> http://www.cidoc-crm.org/cidoc-crm/ for all ontology versions. >> >> >> >> This is the correct answer, according to 2 decades of RDF / Semantic Web >> experience. >> In particular, FOAF, one of the earliest RDF ontologies and written by >> one of the original authors for RDF Dan Brickley, warns us in the >> specification: >> >> Much of FOAF now is considered stable. Each release of this specification >> document has an incrementally increased version number, even while the >> technical namespace ID remains fixed and includes the original value of >> "0.1". *It long ago became impractical to update the namespace URI >> without causing huge disruption to both producers and consumers of FOAF >> data. *We are left with the digits "0.1" in our URI. This stands as a >> warning to all those who might embed metadata in their vocabulary >> identifiers. >> >> (emphasis added). http://xmlns.com/foaf/spec/ >> >> Please, do NOT put a version number into the URIs. It makes everyone's >> lives worse, and breaks interoperability between systems. It also makes it >> much harder for people to upgrade systems and retract/republish data, >> meaning we will leave folks behind in previous versions. It also makes it >> harder to aggregate data, as the same property (say, P2) has different URIs >> in different systems. >> >> I would go so far as to say that, given we already have different RDFS >> and OWL namespaces, that if there was further fragmentation, it would >> further harm adoption and most users would simply pick the one that was >> easiest for them given the already incompatible URIs. >> >> In looking at similar topics (XML namespaces, API versions) the results >> are the same -- URIs should be persistent, and versions / dates make them >> either less persistent or appear out of date, both of which are harmful. >> >> Thanasis has already made a point about not using versioned base URI: >>> *"I am suggesting that classes do not need versions at all. Doing >>> reasoning on a per class and per version basis would be bad practice, no? >>> One would expect that the whole RDF/OWL representation would be used for >>> reasoning. I think class URIs are only used as identifiers. This also >>> avoids the problem of ensuring correct older versions for deprecated >>> classes."* >>> Thanasi, could you please elaborate more on this? It's not clear to us >>> why/how reasoning considering a particular ontology version is affected >>> when versioned URIs are used for the classes and properties. >> >> >> As above, but Thansis is 100% correct - URIs are used as identifiers. We >> wouldn't change the numbers in the ontology (E22, P2 etc) ... in RDF the >> URI has the same function. >> >> >> On Mon, Sep 27, 2021 at 6:41 AM Pavlos Fafalios via Crm-sig < >> [email protected]> wrote: >> >>> Dear all, >>> >>> We (at FORTH) have started working on the URIs management issue, i.e. on >>> how to provide resolvable URIs for the different versions of CIDOC-CRM and >>> its compatible models. We would like to hear you opinion about the >>> following: >>> >>> *(A) HAVING BOTH UNVERSIONED AND VERSIONED ONTOLOGY URIS * >>> >>> The URI http://www.cidoc-crm.org/cidoc-crm/ will always resolve to the *last >>> official* version of CIDOC-CRM ('official' according to the definition >>> here <http://www.cidoc-crm.org/versions-of-the-cidoc-crm>). >>> *A question (also raised by George) is if we want to point to the last >>> 'published' version* (which is *"a stable version of the standard and >>> can be used for implementation, referencing and any other official purpose"* >>> ). >>> >>> In parallel, each version will have its own versioned URI, e.g., >>> http://cidoc-crm.org/cidoc-crm/7.1.1/ for version 7.1.1, >>> http://cidoc-crm.org/cidoc-crm/6.2.9/ for version 6.2.9, etc. etc. >>> >> >> Yes. Best practice would be that the documentation for each version has a >> separate URI, and a common URI can be used to always refer to the latest >> version. >> See: https://www.w3.org/2005/05/tr-versions >> >> This is less important than (C) (people are better at concluding identity >> than machines!) but still important :) >> >> >> >>> *(B) SERVING HTML OR RDF (BASED ON HTTP REQUEST TYPE)* >>> >>> Different content will be served based on the type of the HTTP request. >>> So, if one asks for >>> http://www.cidoc-crm.org/cidoc-crm/ >>> will get either the HTML content >>> <http://cidoc-crm.org/versions/cidoc_crm_v7.1.1.html> of the last >>> official version (using text/html content type), >>> or the RDFS of the last official version (using rdf/xml content type). >>> We will do the same for also the versioned URIs. >>> >> >> Excellent. >> >> >> >>> Now, if one requests a specific class or property, e.g.: >>> http://www.cidoc-crm.org/cidoc-crm/E5_Event >>> will either navigate to the part of HTML content of the last official >>> version which describes this particular class >>> <http://cidoc-crm.org/versions/cidoc_crm_v7.1.1.html#E5> (text/html >>> request), >>> or (for the case of rdf/xml) will get the entire RDFS of the last >>> official version OR the star-view of that particular class (i.e., >>> subclasses, superclasses, incoming properties, outgoing properties). >>> >> >> Star view, or just the term itself. You can always get the entire RDFS by >> going to the namespace. >> >> >> >>> *(D) WHAT WE DO WITH RENAMED AND DEPRECATED CLASSES* >>> >>> *1/ Renamed*: When resolving a class/property (of a specific version) >>> which has been renamed, we can point the user to the information about the >>> renamed class (since semantics stay the same). For example: >>> when asking for http://www.cidoc-crm.org/cidoc-crm/E78_Collection >>> <http://www.cidoc-crm.org/cidoc-crm/7.1.1/E78_Collection>, >>> users will get information about >>> http://www.cidoc-crm.org/cidoc-crm/E78_Curated_Holding >>> <http://www.cidoc-crm.org/cidoc-crm/7.1.1/E78_Curated_Holding> >>> (once URI resolving has been implemented) >>> >> >> Yes, and ... via an HTTP redirect to the new name for the class/property >> please. >> >> >> >>> *2/ Deprecated*: When resolving a class/property (of a specific >>> version) which has been deprecated, we (Pavlos and Elias) suggest not >>> returning anything (404 response code). In our opinion, this makes sense >>> since the ontology version does not anymore contain the requested >>> class/property. In the case of HTML content type, we can also point the >>> user to the Migration Instructions (page 229 >>> <http://www.cidoc-crm.org/sites/default/files/cidoc_crm_v.7.1.1_0.pdf>). >>> Any comments? >>> >> >> Yes, agreed. >> >> >> >>> *(E) COMPATIBLE MODELS * >>> >>> The plan is to follow the same approach for the compatible models. Here, >>> it seems that having versioned URIs for the ontology and the extension >>> models solves the problem of how to point to specific versions (as >>> mentioned by Francesco). We just need to include the versioned namespaces >>> of the considered models in the RDFS. >>> >> >> Yes, agreed. >> >> Thanks! >> >> Rob >> >> > > > -- > Dr. Pavlos Fafalios > Postdoctoral research fellow > Project ReKnow <https://reknow.ics.forth.gr/> (MSCA Individual Fellowship > ) > > Centre for Cultural Informatics / Information Systems Laboratory > Institute of Computer Science (ICS) > Foundation for Research and Technology (FORTH) > and > Visiting Lecturer > Department of Management Science & Technology (MST), > Hellenic Mediterranean University (HMU) > > Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece > Email: [email protected] > Tel: +30-2810-391619 > Web: http://users.ics.forth.gr/~fafalios/ > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- *Thomas Francart* -* SPARNA* Web de *données* | Architecture de l'*information* | Accès aux *connaissances* blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas
_______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
