[Crm-sig] Document for approval

Barry Norton BNorton at britishmuseum.org
Tue Aug 12 20:20:08 EEST 2014


Ah, the mailing list is slow, so I didn’t know you’d replied on list, Mark.

I’ll repeat then that I take no personal offence, and have no reason to do so, either comments on the URI scheme the BM uses nor on the Primer in itself including its use of a generalised projection from that URI scheme.

I didn’t comment on the issue of the typo on p12 (that the identifier should be labelled with a different URI from the object) as likewise I’d already seen Dominic’s reply. To be clear though, that’s nothing more than a typo and I’d already heard that it will be fixed.

My understanding of the use of URIs as identifiers throughout the document is that it reflects the frequent use of Linked Data discussed in Section 8. When needing a concrete syntax for examples I’d be equally happy with, say, Cipher definitions, and happy to then see the URIs dropped in favour of any scalar identifier, but I fear I’d be in the minority. Have you another suggestion (I mean for a syntax to define relationships, not just the idea of using UUIDs as identifiers)?

Barry



From: Crm-sig [mailto:crm-sig-bounces at ics.forth.gr] On Behalf Of Mark Fichtner
Sent: 12 August 2014 17:04
To: crm-sig at ics.forth.gr
Subject: Re: [Crm-sig] Document for approval

Dear all,

it seems that you feel yourself personally offended, Barry. I don't think Georg did mean this, Martin asked for feedback and he got some - personally I think that is the best that can happen for science.

I think many points which Georg mentioned are valid. I don't want to repeat them, I just also got the same impression that Georg got from the document. I want to explain my point of view with PDF pages 13-14 (labeled 11-12 in the document itself - I would suggest to make this consistent, too.):
This paragraph is labelled "9.2 Example of using Entities with Properties with RDF" - so it is an example and examples should be easy to understand because they illustrate important parts. However the image on top of page 14 (or 12 due to the label on the page) is absolutely not the semantically equivalent in rdf to the image on the bottom of page 11 which illustrates the CRM view. A possible correction is illustrated in the attachment.

If you look carefully at the current image, then you can see that it is semantically equivalent to: "http://collection.amuseum.org/id/object/1234 being a E42_Identifier and a E22_Man-made_Object at the same time and refering to itself via P1_is_identified_by." However the crm-example states "There is a Man Made Object which is called The Hoa Hakananai and it is identified by an identifier which is an accession number". This is not what the primer tries to describe above, it is not easy to understand, not logical correct, not the rdf representation of the crm view above and therefore just a bad example in a primer. Thank you for pointing that out, Georg, I didn't see it so clear this way before.


The following part is labelled "9.3 URI Schema" and not "9.3 Examples for a consistent URI Schema". Furthermore it states that "Resources (like an object or an identifier) are assigned a URI providing a logical structure when
implementing RDF. URI schemata are created to reflect the resources in question.". This means that the URI has to provide "a logical structure" - what are the requirements for this "logical structure" in detail? Is a UUID a valid logical structure? Why are all examples URLs?

Perhaps this helps to get this a little bit more constructive.

Best regards,

Mark Fichtner

2014-08-12 17:04 GMT+02:00 Barry Norton <BNorton at britishmuseum.org<mailto:BNorton at britishmuseum.org>>:




-----Original Message-----
From: Crm-sig [mailto:crm-sig-bounces at ics.forth.gr<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<mailto: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

_______________________________________________
Crm-sig mailing list
Crm-sig at ics.forth.gr<mailto:Crm-sig at ics.forth.gr>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

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


More information about the Crm-sig mailing list