[Crm-sig] Document for approval

martin martin at ics.forth.gr
Tue Aug 12 20:33:56 EEST 2014

Dear All,

Just a comment from my side: The CRM does not deal with the ways URIs 
are formed and

I would not like to mess up a document about how the CRM is used with a 
discussion about
how URIs are created.

I would neither like to have an introduction to the CRM using blank URIs 
just to avoid mentioning URIs,
or to use only UUIDs to avoid any prejudice on another scheme or practice.

There is a CIDOC recommendation for URIs for museum objects, for a thousand
other kinds of things we have no official recommendation.

If this helps, I recommend the Primer to contain a disclaimer that the 
way URIs are formed or
selected in the examples of this document are not part of what this 
document wants to render.
It is a task of other standards to solve this issue. In particular, the 
CRM is not a guide to LoD,
but can be used as ontology for Linked Open Data formulation.



On 12/8/2014 7:03 ??, Mark Fichtner wrote:
> 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]" 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 <mailto:Crm-sig at ics.forth.gr>
>     http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig


  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Research Director             |  Fax:+30(2810)391638        |
                                |  Email: martin at ics.forth.gr |
                Center for Cultural Informatics               |
                Information Systems Laboratory                |
                 Institute of Computer Science                |
    Foundation for Research and Technology - Hellas (FORTH)   |
                N.Plastira 100, Vassilika Vouton,             |
                 GR70013 Heraklion,Crete,Greece               |
              Web-site: http://www.ics.forth.gr/isl           |

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

More information about the Crm-sig mailing list