Dear Barry,

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

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

> Further, nothing about the illustrative identifier scheme implies the
> use of a triplestore (I should know, I load our data into other forms of 
> DBMS).

Yes, you are right, it is not explicitly mentioned. Nevertheless when
talking about RDF and Linked Data like the example does, it seems to
be obvious to assume a triple store. If you take a look at Linked Data
Resources available, 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. 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.

> 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]"; what would its
URI look like? 
http://collection.[domain]/id/document-bibliographic_series-skosconcept/[idenitifier]
?


Regards,
Georg

Reply via email to