[Crm-sig] Call for Comments

martin martin at ics.forth.gr
Thu Mar 24 16:47:06 EET 2011


Dear Detlev,

Apologies for my generalizing remarks from yesterday!

A) To take your example:

In paragraph 11, the recommendation says:
•	ICOM has no particular proposal as to how such an aggregator may be decided upon, but it could be based on a leading national or community
role, or a leading research role for a well-defined set of objects.

The http://papyri.info/hgv/ obviously is an aggregator with a leading community
role and a leading research role for a well-defined set of objects.
It therefore falls under the recommendation.

You give http://papyri.info/hgv/ as a positive example, in obvious aggreement
with the recommendation.

Also, http://kulturarvsdata.se was referred to us as a positive example
of a leading national role.

In general, we share your concern that "these institutions are
  sometimes all too willing to take over interesting ("buzzword") duties".
To prevent this, we put as conditions in paragraph 11:

"In the case that a curating organisation or museum takes no such action..."
and
"Such an aggregator must never ignore the wish of a curating institution to provide its own URIs, and must duly publish the mapping of their
URIs to those subsequently generated by the curating institution".
and
"In either case, the delegated authority organisation must have a defined and documented business relationship with the museum that details
how to keep both sides consistent."

Please let us know, if this is not enough to counter your concerns.

Your concern appears actually in contradiction
that you give http://papyri.info/hgv/ as a positive example.

b)you write:
"I believe the recommendation should encourage museums to associate their
URIs with metadata that carries all other known identifiers (if any)".

My understanding of the current situation of digital documentation at
museums is that they may have documented in an average may be 5% of their
holdings. We may estimate for large museums that they will need another
decade or two to create the metadata you talk about.
Your recommendation would mean that in maybe 20 years we shall have a reasonable
coverage of URIs for museum objects from museums.

In the meanwhile, other digital and physical sources refer to museum objects.
Our recommendation enables aggregators like http://papyri.info/hgv/ to
refer to future museum pages already with the correct URI.

It is out the question that a museum curator would "associate their
URIs with metadata that carries all other known identifiers". Firstly, this
job is in the interest of the aggregator, and not the curator, secondly,
it is practically impossible for the curator to trace all references in upcoming aggregation
services in a timely manner.

It is much easier, and in the motivation of a service like http://papyri.info/hgv/
to refer to the object "Cairo, IFAO A 45" (see http://www.trismegistos.org/tm/detail.php?quick=65499)
by, let us say: "http://objects.ifao.egnet.net/A_45", if this were the rule
suggested by IFAO. This identifier may be taken up or independently be used
from the Heidelberg service, until, or if ever, IFAO will have a respective LoD
entry.

If Inventory numbers contain invalid symbols for URIs, the museum can prescribe
the necessary escape sequence by rule.

You write: "Any institution or project with the necessary resources can then stitch
  together related descriptions using a suitable predicate over a pair of
  URIs."

We have shown in:
Carlo Meghini, Martin Doerr, Nicolas Spyratos, Managing Co-reference Knowledge for Data Integration, 2009, Yasushi Kiyoki, Takahiro Tokuda,
Hannu Jaakkola, Xin Chen, Naofumi Yoshida (Eds.): Information Modelling and Knowledge Bases XX, 18th European-Japanese Conference on
Information Modelling and Knowledge Bases (EJC 2008), Tsukuba, Japan, June 2-6, 2008. Frontiers in Artificial Intelligence and Applications
190 IOS Press 2009, ISBN 978-1-58603-957-8.

that correcting a wrong connection in an arbitrary network of equivalent identifier
pairs needs exponential time, not talking about the time to talk to arbitrary stitchers,
and therefore will become catastrophical.

The complexity can only be controlled, if the co-reference clusters center around very
few identifiers in a star-like shape. So, as long as there is one focal point like
http://papyri.info/hgv/65499/and one like "http://objects.ifao.egnet.net/A_45", the world
is under control. The more, the worse.

The Recommendation does not ensure that there is one URI only, nor does it intend to.
It intends to keep the number as small as possible, and to make it as easy as possible
to find those who have the object and know what it is or what it not is. It is already
annoying in http://papyri.info/hgv/, how many steps I have to make to find the keeper
of the object.

It is very impressive to see how many cross-reference errors the University of Frankfurt
has resolved in aggregations of Roman Inscriptions (http://www.manfredclauss.de/).
Such resolution means in the end to go back to the object and the museum.

Paragraph 8 basically describes a variant of the maintenance of the Provenance chain, which is an
existing CIDOC recommendation, and subject of the Getty Provenance Project.


Best,

Martin


On 3/23/2011 5:31 PM, Detlev Balzer wrote:
> Dear Martin and all,
>
> while it is understandable that a recommendation from ICOM-CIDOC takes a
> museum-centric view, this may obscure the fact that some communities
> have been grappling with identity and identifiers for a long time.
> Maximilian has mentioned the art trade, and objects described by
> scholars not affiliated with a particular museum. Let me add another
> example, which is that of papyrology:
>
>    http://papyri.info/hgv/65499/
>
> What we see here is a chain of identifiers that had already been
> compiled into a cumulative catalogue (the Heidelberger
> Gesamtverzeichnis, HGV) before being published on-line.
>
> Rather than pondering the idea of a persistent URI, I believe the
> recommendation should encourage museums to associate their URIs with
> metadata that carries all other known identifiers (if any). Any
> institution or project with the necessary resources can then stitch
> together related descriptions using a suitable predicate over a pair of
> URIs.
>
> This will work even if none of the recommendations outlined in sections
> 8 to 11 (except for the last paragraph in 11) can be followed. So why
> not split up the document into one that describes the absolute
> essentials (constructing URIs, resolving them to processable metadata)
> and another which outlines policies for usage of these URIs by any party
> that wishes to refer to them in their own LOD statements?
>
> One personal remark concerning "leading national or community roles" as
> mentioned in section 11: In my experience, these institutions are
> sometimes all too willing to take over interesting ("buzzword") duties,
> only to realize that their core staff is so busy with routine work that
> the prestigious new task ends up on the desk of an apprentice.
>
> Regards,
> Detlev
>
>
> Am 21.03.2011 17:02, schrieb martin:
>> Dear All,
>>
>> Your comments on http://www.cidoc-crm.org/URIs_and_Linked_Open_Data.html
>> will be most welcome!
>>
>> Best,
>>
>> Martin
>
>


-- 

--------------------------------------------------------------
  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)   |
                                                              |
  Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
                                                              |
          Web-site: http://www.ics.forth.gr/isl               |
--------------------------------------------------------------



More information about the Crm-sig mailing list