I agree with Rob. In the case of Part D, I suggest the HTTP 303 See Other for a replacement/renaming. I agree there shouldn't be a 404 for a deprecation, but there should be a 3xx code for redirecting to the Migration Instructions. 301? Not sure.
On Mon, Sep 27, 2021 at 9:40 AM Robert Sanderson via Crm-sig < [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 > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig >
_______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
