[Crm-sig] Preferred Identifier vs Appellation vs Image
martin at ics.forth.gr
Tue Sep 17 19:38:38 EEST 2013
On 16/9/2013 8:16 μμ, Kai Sommer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Dear all,
> this is my first post on this list and I want to reply to an email
> from Vladimir Alexiev he sent on November 20. last year (2012) .
>  http://lists.ics.forth.gr/pipermail/crm-sig/2012-November/001901.html
> I'm new to CRM (an ontologies), but I have to describe conservation
> objects (artifacts) with CRM.
> Because I'm new, I have some understanding questions. One is similar
> to the original from Vladimir. – So I will ask it here.
> Am 20.11.2012 11:57, Vladimir Alexiev wrote:
>> However, in any system that displays search results, it's important
>> to know two other preferred attributes of an object:
>> 1. Preferred image: to be shown as thumbnail in a result list or
>> 2. Preferred label (name/title/appellation): to be shown as short
>> textual representation of the object
>> 2. Following LOD best practice, we try to make rdfs:label for every
>> I wonder why CRM standardizes 0 but not 1 & 2.
>> Let's say we have these attributes and want to add that they are
>> <obj> P1_is_identified_by <obj/id/1>;
>> P102_has_title <obj/title/1>;
>> P138i_has_representation <obj/image/1.jpg>
First a general remark. CRM-SIG differs slightly in its opinion what an
ontology is from current Semantic Web practice. RDFS files for us are
database schemata, implementations, and not ontologies per se,
regardless how close they come to be an ontology. The reason is, that
ontologies for us are logical theories approximating human
conceptualization, whereas RDFS or OWL files have an encoding bias,
which becomes apparent in the identifier/label question.
The CRM will continue to make this distinction, because there must be a
definition of the ontology that survives different encoding trends. This
does not mean that CRM-SIG is not interested in giving recommendations
for implementations, but they are at another logical and managerial
level. CIDOC CRM as ISO21127 will stay encoding neutral.
> Can someone explain (maybe by an example) me how (and when) to use the
> following properties correctly, please.
> * P1_is_identified_by
P1 is the ontological definition of the relationship between a real
world instance as we perceive it and an identifier for it by which we
refer to it, such as a name, and inventory number or a URI.
In some ooDBMS, the real world instance would be represented with a
hidden object identifier, and user would see another, explicit one. In
RDF, the instance would be represented with one "preferred" URI
directly, without an additional link. In RDF, we can assign names to
instances by rdf_label, by an explicit link or using its URI. Therefore,
the CRM property P1 stands in RDF for 3 possible ways to express a name
for an instance.
If we use P1 in RDF, we must be clear that is does not give the correct
answer from a pure logical CRM perspective. In order to query for all
items by which an instance "P1 is identified by" we would need to write
code, which returns the unique URI of the instance, the explicit
declarations of P1 and all rdf_label of it, IF ! rdf_label is used to
> * P48_has_preferred_identifier
This is NOT the identifier we prefer to display in an application, but
the identifier an organization encourages to use for their objects. This
should only occur if the organization has changed their identifiers, and
wants to declare all others as obsolete. It is debatable, if this
property should stay in this form in the CRM at all, because the
organisation is implicit in its definition.
> * P102_has_title
Is a special kind of identifier, a non-unique name typically assigned by
the creator which may also render a meaningful message. The concept is
well-defined in librarianship, and CRM recommends their good practice to
use it. In museum systems, "title" is often a categorical description
chosen by the curator. This is not meant with this property.
We may consider to make it in RDF a subproperty of RDF label.
> I read the comments for this properties, but it's not really clear or me.
> Q1: Can P1_is_identified_by be used instead of rdfs:label (like
> Vladimir wrote above)?
> Q2: Is it correct to use P1_is_identified_by for any (internal or
> abstract) identifier, like an inventory number or so? (If yes, this
> identifier is a literal an not a new object …)
I would recommend to use rdf_label for any non-unique (non-URI) identifier.
> Q3: Is P48_has_preferred_identifier usable as the 'real' title/name of
> an artefact? – The comment says "to identify an instance […] at the
> time this property was recorded". Does "recorded" means the first
> name/title I know?
No. It means the time when the organisation regarded the identifier as
preferred and therefore registered it as the preferred one. Don't use
P48, if it is ambiguous or if you do not have multiple identifiers.
You can extend the CRM or subtype rdf_label to express other semantics.
> Q4: What is P102_has_title for? – I can use P1 and P48 … :-/
> Finally I have a generally question:
> If I express a relation (i.e. P1; see example above) in RDF wit CRM.
> Do I have to express the inverse relation (P1i_identifies) in the
> object (<obj/id/1>) explicit or is the inverse relation
> always/automatically (inplizit) there?
For CRM, there are no inverse relations. All relations are bidirectional
and directed. This is another encoding bias of RDF, don't know what this
feature was ever good for. There is no equivalent in many other data
models. So, inverse relations are always meant to be implicit and
automatically existing. It is your problem, how you implement that:
query all properties forward-backward,
create always pairs, or use OWL and a reasoner to create the pairs.
> At the moment I think – excuse my lack of knowledge – that the answer
> of the last question makes the difference of CIDOC-CRM and Erlang-CRM.
> – In CIDOC-CRM I have to make the inverse relations explizit and in
> Erlang-CRM it is implizit.
> → Is it true …!?
> Excuse me for asking such ('stupid') questions (with such a rusty
You are welcome!
> Best regards,
> Kai Sommer
> Don't hesitate to tell me if this is not the right list for asking
> such questions and show me the right one! :)
> - --
> Fachhochschule Potsdam | http://www.fh-potsdam.de
> Informationswissenschaften (FB5) | http://iw.fh-potsdam.de
> Master Informationswissenschaften | 3. Semester
> sig: 1E6B 06F5 EBE5 6FE2 | pubkey: http://ma.ximi.se/fhpkey
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
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 |
More information about the Crm-sig