[Crm-sig] URI Management [Issue 460]

Detlev Balzer db at balilabs.de
Mon Sep 27 18:39:37 EEST 2021


Dear all,

good to see that the idea of publishing some of the CIDOC CRM as a Linked Data resource is finally gaining traction.

Concerning versioning, I'm also in favour of a single, un-versioned URI namespace, as long as there is a way of knowing which version is currently being served (e.g. by including statements from the W3C VoID vocabulary). Nevertheless, having previous versions accessible via additional, versioned namespaces can be useful for tracing conflicts that may arise from non-backward-compatible changes. 

Regarding the question of "star view" vs. complete schema, I'd suggest to follow the common practice of serving just the direct statements where the class or property URI occurs as the subject. This is basically what you get from SPARQL using a DESCRIBE <uri> query. In an HTML view, you probably want to see more context such as inferred statements. Pure RDF however, is intended for machine processing and if you make all of the RDFS availabe via SPARQL (in addition to resolving URIs directly), then anyone is free to construct their own "star view" as required.

Concerning HTTP 3xx redirections, I would not take this too far. It may make some sense for HTML pages, but less so on the level of RDF processing.

Just a few thoughts from the depths of the engine room ...
Detlev

> Pavlos Fafalios via Crm-sig <crm-sig at ics.forth.gr> hat am 27.09.2021 16:03 geschrieben:
> 
> 
> 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 <azaroth42 at gmail.com> 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
> 
> 
> 
> -- 
> 
> 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: fafalios at ics.forth.gr 
> Tel: +30-2810-391619 
> Web: http://users.ics.forth.gr/~fafalios/
> _______________________________________________ Crm-sig mailing list Crm-sig at ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig



More information about the Crm-sig mailing list