Dear Vladimir,
Just let me give you some theoretical background for this question,
without taking any particular position
to your proposal:
The CIDOC CRM is built following some explicitly stated principles, see,
for instance:
http://www.cidoc-crm.org/scope.html
In order to avoid modeling the whole world, we use as absolute criterion
of relevance of concepts
to be included in the CRM that some relevant community actually
documents explicitly or implicitly using these
concepts. All constructs in the CRM are or should be example based. This
is also to avoid that constructs
enter the CRM which we have not fully understood in practice, and may
later need to revise. This is not
an ontological principle, but a managerial one, and a particularly
successful one so far. This does not mean that
symmetry is not an argument for the CRM, as you pose it.
So, all practice of the British museum is relevant, and new evidence for
CRM-SIG. This is why CRM-SIG
has to consider this new evidence from the issue you submitted in the
next meetings and may introduce new constructs to describe this
practice, if there are no other adequate ways.
A second principle however is, that an ontology in the proper sense is
not a database schema. So, the
fact that links are drawn across the world by experts does not mean that
these connections exist as
elements of an ontology, but rather as deductions. In particular, if
there are intermediate objects in such
deductions that play an important role as subjects of independent
documentation, we would not
shortcut over them. If there is any essence of integration via the CRM,
it is that overly shortcutting inhibits
reasonable information integration.
In the case of physical objects having inscriptions, there are large
corpora of inscriptions assigning individual
identity to the inscription. Therefore, in general, we did not regard as
a good model to "wash over" the inscription
as an object in its own right, by providing a shortcut from the physical
object to referred things in a text on them.
So, in general, the intermediate object must be regarded as relevant for
information integration, and a shortcut
may be regarded as counterproductive to information integration?
Inscriptions have a different notion of identity from the shape of a
material object, such as a statue, depicting someone or something. They
can be represented in a discrete, abstract form, whereas the shape or
color distribution is intrinsically analog. That might be a good reason
to distinguish both forms of "reference".
The question if you can distinguish from your data if the script writer
is mentioned in the text on the object or
inferred from background knowledge is not a problem of the ontology, but
an epistemological one, i.e., to
be clarified with the curators what their practice is. If the actual
data do not allow for sufficient disambiguation,
any implementation of an integration system is free to use other
relationships, such as Dublin Core, to capture underspecified
documentation, without violating import compatibility, but this is no
more CRM export compatible.
Of course there exist data which we regard as not CRM compatible because
of underspecified semantics, and there is nothing we can do about. The
argument being here that the curator is able to specify if the script
writer is explicitly referred to or not in an inscription. Therefore
this is not a natural state of "not knowing" of a curator.
Further, if you know how to handle the respective deductions in your
system, you can introduce,
without violation of CRM compatibility, your own local shortcuts. What
that means for query compatibility and export compatibility in terms of
implementation, is a technical issue. The CRM is explicitly defined not
to serve database optimization issues, and therefore CRM compatibility
is not defined on the base of the schema, but on the external behavior
of your system only.
Having said this, we might quite well come to the decision, that an RDF
implementation, being actually a schema and no more a pure ontology,
might consider optimization issues beyond CRM definitions. In order to
avoid a proliferation of "official" versions, I'd prefer however to keep
a common core of minimal ontological commitment.
Best,
martin
On 10/7/2012 10:53 πμ, Vladimir Alexiev wrote:
But the object does not "refer to" the scriptwriter. In fact the link to the
script writer is purely in the documentation of the object.
How do you know this? Do you know the BM data better than its original creators?
The BM curators must have had a reason to include that reference in the BM data
(table Associated Person).
Maybe there's an incription in the drawing that mentions the play and the
script-writer.
It is not represented as an inscription (merely as a reference), so we cannot
map it to E34_Inscription,
but we want to capture it as a "refers to" property.
what is your justification for having P62_depicts, but not having the properties denoted
"???" in my original email?
we saw P62 used in actual data models and so we provided it as a short-cut (you
are quite correct it is a short-cut!).
We have not seen the others and so had no justification for creating them
Ok, so the reason for lacking these shortcuts is not logical or ontological, it's merely
"no established practice".
Now 3 people gave examples (trying to establish practice), yet it seems you
discount them as somehow incorrect.
But since there is no ontological argument *for* P62 and *against* the "???"
shortcuts,
all of your counter-arguments can be turned against P62 as well!
Best regards! V
_______________________________________________
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 |
--------------------------------------------------------------
