[Crm-sig] URI Management [Issue 460]

Thomas Francart thomas.francart at sparna.fr
Sun Oct 3 23:21:16 EEST 2021


Hello

I strongly support unversionned URIs. Versionned URIs will be hell to
maintain, to explain, to consume.
It is the _dataset_ (in the sense of DCAT) that should be versionned at
each release, not the URIs declared inside it.
It was mentionned in the original message that *"When one builds a
knowledge base (RDF dataset) using cidoc-crm, he/she considers a particular
version of the model. "* I think the use-case of upgrading the version of
the CRM inside a system originally built with a previous version should
also be considered, and in that perspective, having stable URIs is
necessary.

FWIW, in a different context (SKOS Concepts), but similar problematics
(versionning) I had developped a timeline views in concept pages, allowing
to see in which version the concept was introduced, in which version it was
deprecated, and enabling a user to switch between the version to display
the concept in any version of the vocabulary. See :

   - Here for a random concept still in force :
   https://www.reseau-canope.fr/scolomfr/data/scolomfr-7-0/fr/page/?uri=http%3A%2F%2Fdata.education.fr%2Fvoc%2Fscolomfr%2Fconcept%2Fscolomfr-voc-015-num-1201
   - Here for a deprecated concept :
   https://www.reseau-canope.fr/scolomfr/data/scolomfr-7-0/fr/page/scolomfr-voc-045-num-001
   (marked with owl:deprecated + dct:isReplacedBy)


Cheers
Thomas


Le lun. 27 sept. 2021 à 16:10, Pavlos Fafalios via Crm-sig <
crm-sig at ics.forth.gr> a écrit :

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


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20211003/4c46dd1f/attachment-0001.html>


More information about the Crm-sig mailing list