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 Primer mentions in passing that URIs in the scheme from an object root might include /material, but says no more about this case, nor indeed the standard one).
In fact in those 15 cases where the material is defined relative to a BM object, rather than by being a standard thesaurus term, it's because the material is associated with a unique material creation event associated with the object and is not named and included in our thesauri. That being said, one should not attempt to 'read' URIs, that's a basic principle of REST as much as Linked Data; what's important about the thesaurus terms is their relatedness under skos:inScheme (not their URI path). 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). The problem you mention about 'multiple inheritance' counts only under the unique name assumption, which holds neither in REST nor Linked Data. Regards, Barry -----Original Message----- From: Crm-sig [mailto:[email protected]] On Behalf Of Georg Hohmann Sent: 12 August 2014 08:58 To: [email protected] Subject: Re: [Crm-sig] Document for approval [...] - The proposed URI schema (p12) does not reflect the structure of a triple stores and knowledge graphs. In the example given the URIs themselves reflect paths inside a graph from a given starting point. It seems that "object" is a favourite starting point, and also "thesauri". But who decides on which point to start? For example, "http://collection.[domain]/id/object/[idenitifier]/material"; might also be "http://collection.[domain]/id/material/[identifier]";. Additionaly, using class names inside a URI becomes instantly painful when it comes to multiple inheritance. To implement the URI scheme in the given format would imply to use a triple store against its internal structure.
