[Crm-sig] Document for approval

Barry Norton BNorton at britishmuseum.org
Tue Aug 12 18:04:06 EEST 2014





-----Original Message-----
From: Crm-sig [mailto:crm-sig-bounces at ics.forth.gr] On Behalf Of Georg Hohmann
Sent: 12 August 2014 15:33
To: crm-sig at ics.forth.gr
Subject: Re: [Crm-sig] Document for approval



>> Georg, your comment about the URI scheme into which a given material

>> fits seems motivated not by the Primer but rather by the British

>> Museum data

>

> Since the the URI scheme of the BM is given as a linked data example in the primer, my comments are about the texts

> and the figures in the primer and the purpose they serve.



The mention of /material in the example URIs is just an arbitrary example of object-specific resources and I've agreed with Dominic that this can be changed or dropped if it confuses.



Again, the Primer does not cover that there are two sources of resources for materials in the BM data; the confusion only arises when you look at a larger example than the Primer and don't examine resources in terms of their relationships but instead focus on the URIs.





>> That being said, one should not attempt to 'read' URIs, that's a basic

>> principle of REST as much as Linked Data;

>

> Yes, for sure. So why should a primer include an example that creates the appearance that URIs

> should have a structure that makes them "more readable" for humans?



If that's the impression then it should be clarified. As it standard for REST over HTTP the URIs should be crafted to be maintainable for the service provider (which is the intention of this exemplar scheme), not transparent to the user.





> it will be hard to find any other resource that mints URIs the way that is given in the primer, because -

> as you said yourself - it is not common practice.



Well, I don't think I've said that, but equally it's not intended to be(come) common practice. The URI scheme of the Primer illustrates that one can establish a consistent hierarchical URI scheme to publish data according to the CRM, not that one must follow the particular scheme used in examples (which seems to offend you because it's a projection from the BM one, but it's only an example of what one could use).





> As you deal with other kinds of DBMS than triples stores you might have good reasons to expose your data that way,

> but then it is a special case that is not suitable for a example in some kind of primer.



You misunderstand me. Loading the data, adhering to both the CRM and the identifier scheme, was post hoc and had no effect on the URI scheme. My intention was to confirm that there's no triplestore bias in the common practice of a hierarchical URI scheme.





>> The problem you mention about 'multiple inheritance' counts only under the unique name assumption, which holds neither in REST nor Linked Data.

>

>By refering to "multiple inheritance" I refer to the fact that any instance can be an instance of one, two or more classes at the same time.

> If you have the name of the classes inside a URI, you should have a rule on how to deal with multiple names.

> For example: In the last figure (p.20) "A Bibliographic Object" is rdf:type of many classes.

> According to the given URI scheme "http://collection.[domain]/id/object/[idenitifier]<http://collection.[domain]/id/object/%5bidenitifier%5d>" what would its URI look like?

> http://collection.[domain]/id/document-bibliographic_series-skosconcept/[idenitifier<http://collection.[domain]/id/document-bibliographic_series-skosconcept/%5bidenitifier>]



Sorry, but then you're inventing a convention different from the example in the Primer and then criticising it. Isn't that just a straw man?



The Primer does not say 'use class names in minting your URIs', nor does it have examples that do so (cf. the very figure to which you refer).



Barry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20140812/a38312f5/attachment-0001.html>


More information about the Crm-sig mailing list