[Crm-sig] URI Management [Issue 460]

Pavlos Fafalios fafalios at ics.forth.gr
Mon Sep 27 17:11:20 EEST 2021

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).


On Mon, Sep 27, 2021 at 4:55 PM Ethan Gruber <ewg4xuva at 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 at ics.forth.gr> wrote:
>> Reordering to most important first..
>>> 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 at 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:
>>> 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 :)
>>> 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.
>>> *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.
>>> 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 at 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)
Visiting Lecturer
Department of Management Science & Technology (MST),
Hellenic Mediterranean University (HMU)

Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
Email: fafalios at ics.forth.gr
Tel: +30-2810-391619
Web: http://users.ics.forth.gr/~fafalios/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210927/3d37f85a/attachment.html>

More information about the Crm-sig mailing list