[Crm-sig] Document for approval

martin martin at ics.forth.gr
Wed Aug 13 22:56:56 EEST 2014

Dear Vladimir,

Thank you for your detailed comments! From my side, just one remark:

 From the side of CRM-SIG so far we *do* recommend not to use SKOS:Concept
for places and persons, regardless if such practice exists. It is 
logically inconsistent.
The separation of particulars and universals is fundamental to knowledge 
This has been supported equally clearly by the FRBR Review Group. 
Literary characters
based on Persons have clearly been separated from real persons in FRBRoo.



On 13/8/2014 8:16 ??, Vladimir Alexiev wrote:
> Dear all,
> (Everything quoted is response to Georg's comments)
> Such a document is greatly needed by the community.
> 0. Martin, maybe there's some breakage on the site:
> http://www.cidoc-crm.org/technical_papers.html and
> http://www.cidoc-crm.org/working_editions_cidoc.html
> return just a single unicode char.
> 1. May I suggest you put it on Google Docs, so we can comment inline?
> I have a some very specific comments that would be inconvenient to make in email.
> - E.g. "Nick Crofts" and
> "Chair of ICOM CIDOC and Vice Chair of the ICOM Advisory Committee"
> being separated by a page break.
> 2. I think the examples should be made in Turtle.
> The approach with tables is inconvenient typographically (observe the middle column),
> harder to understand (have to repeat the object in every row),
> and cannot be validated programmatically.
>> always a good decision not to
>> "approve" and "ideal" implementation of the CRM. In fact, the second
>> part does right that in outlining an implementation of the CRM in RDF
>> / Linked Data. If we consider this part as some kind of "good
>> practice"...
> 3. Such "good practices" are crucial to achieve real interoperation between collections.
> So it's a good thing that Dominic's writing about them.
> 4. Accepting such "good practices" will take a lot of discussion and collaboration, but the result will be worth it.
> However, I am convinced that we need a wiki to develop such "good practices":
> doing it in a monolithic document will not scale.
>> "http://collection.[domain]/id/object/[idenitifier]/material" might
>> also be "http://collection.[domain]/id/material/[identifier]"
> 5. "http://collection.[domain]/id/object/[idenitifier]/material" should be removed from the doc: ideally, the consists_of value of an object should come from a thesaurus, so the second form is correct.
> 6. This is unlike http://collection.amuseum.org/id/object/[identifier]/accessionnumber, which is an Identifier local to the object, so it makes sense for its URL to be nested under the object's.
>> - The figure on p.12 ("Here is the RDF view") shows an instance
>> "http://collection.amuseum.org/id/object/1234" that is connected to
>> itself(!) by the property P1.
> Yes, the right node should be http://collection.amuseum.org/id/object/1234/accessionnumber
> 7. The intro section should cover a bit more of the class hierarchy (at least the physical/conceptual partition),
> and explain shortcut/longcut (which is mentioned at the end)
>> 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]
>> ?
> 8. No: "object" means "a museum object" or "cultural heritage object".
> There's no implication that the URI will carry part of a CRM class name.
> So http://collection.amuseum.org/id/bibliography/<id> is correct.
>> - The figure on p.14 mixes up authority terms with classes and
>> instances. It shows that the "type" of a production should be
>> expressed as directly by assigning a "P2 has type". I think something
>> like "Engraving" would be a "E29 Design or Procedure".
> 9. So instead of this:
>    <object/ID/production> P2_has_type <thes/production/engraving>.
> you're proposing that:
>    <object/ID/production> P33_used_specific_technique <object/ID/production/engraving>
> This is wrong, because "E29 Design or Procedure" should be a specific procedure ("engrave X in the left corner, Y in the right corner, use concentrated acid, call Z if you burn yourself").
> But in the example we have merely an enumeration of types, i.e. a thesaurus.
> For Engraving, this is suitable and perhaps better than P2_has_type:
>    <object/ID/production> P32_used_general_technique <thes/production/engraving>
> But for some other kinds of production (e.g. Publishing), I think P32_used_general_technique is worse,
> because would you call  Publishing a "technique"?
>> A thesaurus of production types is an instance of
>> "E32 Authority Document".
> 10. Or a skos:ConceptSchema, as in the current BM LOD.
>> The property
>> "P7 took place at" has the range "E53 Place" and not some theaurus
>> term as indicated.
> 11a. In the current BM LOD these are both E53_Place and skos:Concept.
> 11b.But for the Getty TGN I've adopted a "Concept vs Place Duality":
> http://vladimiralexiev.github.io/aat/index.htm#Concept_vs_Place_Duality
> For example:
> tgn:3000034 a gvp:AdminPlaceConcept; # Great Lakes Region
>    gvp:broaderPreferred tgn:1000001; gvp:broaderPartitive tgn:1000001; # North and Central America
>    gvp:tgn3000_related_to tgn:7029370; # Great Lakes (lakes)
>    foaf:focus tgn:3000034-place.  ######## see here ########
> tgn:3000034-place a wgs:SpatialThing, schema:Place;
>    wgs:lat "45.0000"; wgs:long "-85.0000"; wgs:alt "183.1840";
>    schema:geo tgn:3000034-geometry.
> tgn:3000034-geometry a schema:GeoCoordinates, schema:GeoShape;
>    schema:latitude 45.0000; schema:longitude -85.0000; schema:elevation 183.1840;
>    schema:box "-92.0160,43.1560 -92.0160,48.8120 -82.4910,48.8120 -82.4910,43.1560 -92.0160,43.1560".
> VIAF, FR, UK, SE follow this approach.
> US, DE don't follow this approach.
> The approach has its share of disadvantages :-(
> http://vladimiralexiev.github.io/aat/index.htm#Cons_of_the_Dual_Approach
> 12.Acquisition example (p.17)
> - no explanation why Acquisition Element 1 and P9_consists_of is needed.
> - P29_custody_received_by is attached to wrong nodes.
> 13. Production example (p.18)
> - Period-Culture has wrong URL;
> and "Material Culture authority" should be renamed to "Period-Culture thesaurus" to avoid confusion
> Cheers! Vladimir
> _______________________________________________
> 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/20140813/e7e6071a/attachment-0001.html>

More information about the Crm-sig mailing list