[Crm-sig] URI Management [Issue 460]

Ethan Gruber ewg4xuva at gmail.com
Mon Sep 27 16:55:39 EEST 2021


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..
>
>
>> *(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 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:
>>
>> *(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 at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210927/4ace9833/attachment.html>


More information about the Crm-sig mailing list