[Crm-sig] Preferred Identifier vs Appellation vs Image

martin martin at ics.forth.gr
Tue Sep 17 19:38:38 EEST 2013


Dear Kai,


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) [0].
>
> [0] 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
>> lightbox
>>
>> 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
>> object.
>>
>> […]
>>
>> I wonder why CRM standardizes 0 but not 1 & 2.
>>
>> […]
>>
>> Let's say we have these attributes and want to add that they are
>> preferred:
>>
>> <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 
name things.


> * 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)?
right.
> 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 … :-/
see above.
>
> 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 …!?
See above.
>
> Excuse me for asking such ('stupid') questions (with such a rusty
> English)!
You are welcome!

Martin
>
> Best regards,
> Kai Sommer
>
> PS:
>    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)
>
> iEYEARECAAYFAlI3POIACgkQHmsG9evlb+IrNgCfWxPm2NKk97NRUh23Z6QjzjUV
> MTEAn01tpFhmm8B1ZXQ50D4mRFwmO7cf
> =IaET
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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           |
--------------------------------------------------------------



More information about the Crm-sig mailing list