[Crm-sig] URI Management [Issue 460]

Pavlos Fafalios fafalios at ics.forth.gr
Fri Oct 1 17:15:51 EEST 2021


Dear all,

Thank you for the feedback and comments. I created the below google doc
where the different issues related to URI management are summarised.

https://docs.google.com/document/d/1pU_WJcCU5R-Fz_NTU1VcjhocLG--rsb04xW9dqrCjC4/edit?usp=sharing


There will probably be a slot on this at the forthcoming SIG meeting, so
that we can make the final decisions.

Please kindly check the doc before the next SIG meeting and feel free to
comment, especially in case I forgot something (or something seems not to
be the case), or directly reply to this email.

Thank you all again for the contribution.

Best regards,
Pavlos

On Tue, Sep 28, 2021 at 7:19 PM Christian-Emil Smith Ore <
c.e.s.ore at iln.uio.no> wrote:

> I agree with Gordon.
>
> Vest,
>
> Christian-Emil
>
>
> ------------------------------
> *From:* Crm-sig <crm-sig-bounces at ics.forth.gr> on behalf of Gordon
> Dunsire via Crm-sig <crm-sig at ics.forth.gr>
> *Sent:* 28 September 2021 18:05
> *To:* Ethan Gruber; Ethan Gruber via Crm-sig; Pavlos Fafalios
> *Subject:* Re: [Crm-sig] URI Management [Issue 460]
>
> All
>
> I do not think it is good practice to limit access to deprecated resources
> by intercepting requests. A general coded response may trigger an exception
> in a consuming application, but no appropriate action can be taken until
> the specific reason is known. In the case of deprecation, appropriate
> action might include replacing the deprecated resource in the local
> application, removing the deprecated resource, or leaving it untouched (in
> which case the application remains out of synch with the CRM - but that is
> their choice).
>
> I think it is better to return deprecated resources on request, but
> clearly mark them as deprecated. A consuming application can set up an
> exception when the mark is encountered (or not, if synchronization is not
> an issue).
>
> I don't think there is any commonly-agreed method of marking the status of
> resources. For what it's worth, the RDA Registry uses a local status
> property and coded value (see
> http://www.rdaregistry.info/rgAbout/updates/deprecation.html).
>
> Redirection to a 'better' or replacement non-deprecated resource can be
> handled by publishing a mapping from the deprecated resource. Again, this
> is more flexible for consuming applications, and is also easier to maintain
> and manage. Human redirection can be handled by a comment attached to the
> resource.
>
> On 27/09/2021 15:29 Ethan Gruber via Crm-sig <crm-sig at ics.forth.gr>
> wrote:
>
>
> What about 410 Gone:
>
> "Indicates that the resource requested is no longer available and will not
> be available again. This should be used when a resource has been
> intentionally removed and the resource should be purged. Upon receiving a
> 410 status code, the client should not request the resource in the future.
> Clients such as search engines should remove the resource from their
> indices.[42]
> <https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#cite_note-HTTP_410-43>
> Most use cases do not require clients and search engines to purge the
> resource, and a "404 Not Found" may be used instead."
>
> So if you request a deprecated property/class with content negotiation for
> application/rdf+xml, the response you get tells you it no longer exists. I
> think the semantics of 410 are more clear than 404.
>
> There are probably multiple scenarios for redirections.
>
> Deprecated and replaced with a single new URI: 303 See Other
> Deprecated and replaced with more than one URI: 300 Multiple Choices (in
> this case, you can use the Link HTTP header to provide multiple links, but
> the user will have to make a choice).
> Deprecated and not replaced at all: 404 or 410.
>
> We have similar scenarios in dealing with new editions of Roman coin
> typologies. A new volume might have decided that one typology from an old
> volume is now actually two typologies. So we implemented 300 Multiple
> Choices when people request the URI from the old volume. Otherwise, in 1:1
> relations between the old and new volume, it's a 303.
>
> Ethan
>
> On Mon, Sep 27, 2021 at 10:11 AM Pavlos Fafalios <fafalios at ics.forth.gr>
> wrote:
>
> 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 <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..
>
>
> *(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
>
>
>
> --
> 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
>
>
> Cheers
>
> Gordon
>


-- 
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20211001/2dd8363e/attachment-0001.html>


More information about the Crm-sig mailing list