Thank you Ethan. Redirecting to Migration Instructions for a deprecated class seems reasonable when the request is of type HTML. However, I think this is impossible when the request type is RDF/XML; we either point to 404 or (?) redirect to some other class, e.g., the one mentioned in the migration instructions (e.g., using 303). Not sure if the latter is a good option (it also does not seem straightforward to implement in some cases, e.g. for P88, P115 and others).
Best, Pavlos On Mon, Sep 27, 2021 at 4:55 PM Ethan Gruber <ewg4x...@gmail.com> wrote: > 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 < > crm-sig@ics.forth.gr> 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 < >> crm-sig@ics.forth.gr> 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 >> Crm-sig@ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> > -- 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: fafal...@ics.forth.gr Tel: +30-2810-391619 Web: http://users.ics.forth.gr/~fafalios/
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
