[Crm-sig] Document for approval

Mark Fichtner m.fichtner at wiss-ki.eu
Tue Aug 12 19:03:34 EEST 2014


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

>
>
>
>
> -----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]" what would its URI
> look like?
>
> >
> http://collection.[domain]/id/document-bibliographic_series-skosconcept/[idenitifier
> ]
>
>
>
> 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
> 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/453c7b3d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crmprimer.pdf
Type: application/pdf
Size: 93532 bytes
Desc: not available
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20140812/453c7b3d/attachment-0001.pdf>


More information about the Crm-sig mailing list