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
representation.
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.
Best,
Martin
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
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
--------------------------------------------------------------
