RE: RDF recommendation should include rdfs:label

[Vladimir Alexiev]

> Sent: Friday, December 23, 2011 8:08 AM
> It would be very useful if the RDF recommendations of CRM include
rdfs:label for
> properties and classes.
> These can be used in applications to print out classes and properties.
> CIDOC RDFS and Erlangen CRM include only rdfs:comment, which is the scope
note
> and is too long.

I've created such file, see attached. In addition to rdfs:label, it also
defines dc:identifier, e.g.:

crm:P137_exemplifies rdfs:label "exemplifies";
dc:identifier "P137".
crm:P137i_is_exemplified_by rdfs:label "exemplified by";
dc:identifier "P137i".

[Vladimir Alexiev]

I think some of the owl:disjointWith statements should be removed from ECRM:

1. ecrm:E79_Part_Addition ecrm:E80_Part_Removal
Transfer of ownership (or custody) often involves the Removal of an object from one collection and its Addition to another.
This is ONE event that should be modeled as ONE node, having both classes, and all attendant properties from both.

2. ecrm:E18_Physical_Thing ecrm:E28_Conceptual_Object

In a Rembrandt data import for ResearchSpace we use a "compound":
crm:E31_Document (conceptual object) and crm:E84_Information_Carrier (its physical embodiment).
Consider this example (<obj/2926> is a painting, and <obj/2926/document/1> is an XRay of it):

<obj/2926> crm:P70i_is_documented_in <obj/2926/document/1>.
<obj/2926/document/1> a crm:E31_Document, crm:E84_Information_Carrier;
crm:P128_carries <obj/2926/document/1>; # the physical document (E84) carries its conceptual self (E31)
crm:P2_has_type rkd-documentation:X-ray_film;
crm:P50_has_current_keeper rkd-institution:Koninklijk_Kabinet_van_Schilderijen_Mauritshuis;
crm:P55_has_current_location <obj/2926/document/1/location>.

The reasons for such collapsing are:
- we have info about physical properties (keeper, location, size) that need E84
- to say that the XRay documents the painting, that needs E31
- E31 and E84 are one-to-one and we don't have any info about digitization
- we want to save on nodes and complexity, so we equate E31 and E84, and usea self-link P128

Here's what Martin said about this:
"If you take something to be E18-E28 simultaneously, you must be sure in the future you will never have to distinguish between two carriers of the same thing.
So, as long as the X-Ray film, the E18, is used as only source of the information, everything works fine.
If you digitize the film, then it may become messy, but if digital representations are regarded to "show features of" the original, we do not run into a problem with the E18-E28 compound."

[Georg Hohmann]

Dear Vladimir,

in my opinion the first disjoint can be discussed, the second one
seems to be correct the way it is.

1. Part Removal and Part Addtion may be considered as one event in
real life. Although for me it is clear that these are two events, as
the one event (in your example) is to take an object out of a
collection, and the other one is to add an object to an collection.
These events might take place at the same time, but nevertheless theay
are two events. The CIDOC CRM claims to be an ontology for the
cultural heritage and museum domain. For example, The Spectrum
Standard talks about Acquisition (Accession, p. 63ff) and Deaccession
(p. 199ff) as two different events. Therefore, in my opinion the
disjoint still holds.

2. There may be examples on how somebody modelled an instance as both
Conceptual Object and Physical Thing, but this makes no sense in real
life. You seem to argue on a technical level, but in semantics, what
should this be: A thing, that is at the same time immaterial and
material? (And we are not talking about quantum effects ;-)). The
CIDOC CRM itself states: "E18 Physical Thing is disjoint from E28
Conceptual Object". (p. xvi). If Martin argues that an item can be a
Conceptual Object and Physical Thing at the same time, his statement
is not standard compliant. Can you tell me the document where it makes
such a claim?

Best regards.
Georg

On 23 Mai, 14:40, "Vladimir Alexiev" <vladi...@sirma.bg> wrote:
> I think some of the owl:disjointWith statements should be removed from ECRM:
>
> 1. ecrm:E79_Part_Addition       ecrm:E80_Part_Removal
> Transfer of ownership (or custody) often involves the Removal of an object from one collection and its Addition to another.
> This is ONE event that should be modeled as ONE node, having both classes, and all attendant properties from both.
>
> 2. ecrm:E18_Physical_Thing      ecrm:E28_Conceptual_Object
>
> In a Rembrandt data import for ResearchSpace we use a "compound":
> crm:E31_Document (conceptual object) and crm:E84_Information_Carrier (its physical embodiment).
> Consider this example (<obj/2926> is a painting, and <obj/2926/document/1> is an XRay o

[Vladimir Alexiev]

> in my opinion the first disjoint can be discussed,

> 1. Part Removal and Part Addtion may be considered as one event in
> real life. Although for me it is clear that these are two events, as
> the one event (in your example) is to take an object out of a
> collection, and the other one is to add an object to an collection.
> These events might take place at the same time, but nevertheless theay

> are two events. For example, The Spectrum

> Standard talks about Acquisition (Accession, p. 63ff) and Deaccession
> (p. 199ff) as two different events.

There are several cases in CRM where one event has two "dual parts":
- E8 Acquisition: transferred title from, transferred title to
- E9 Move: moved from, moved to
- E10 Transfer of Custody: custody surrendered by, custody received by

If your argument above is correct (and the SPECTRUM example you give relates directly to E8),
then shouldn't you argue for splitting them into 3 pairs?

Part Removal and Part Addition are related just like the 3 examples above.
So please don't declare them disjoint.

(( There is even a case where two UNRELATED events are put together:
- E15 Identifier Assignment: assigned, deassigned
))

---

> the second one seems to be correct the way it is:

> 2. There may be examples on how somebody modelled an instance as both
> Conceptual Object and Physical Thing, but this makes no sense in real

> life. You seem to argue on a technical level, but in semantics...

Ok, I agree.
But mind you, this will require the creation of many "parasitic" (empty) nodes,
since CRM provides fewer relation properties for Physical than for Conceptual
(see thread "ISSUE: P62 needs a parent and a sibling" in [Crm-sig])

E.g. here is an example from mapping British Museum association data:
- Depicted Place
<obj> P62_depicts <place>.
- Referred Place
<obj> P128_carries <obj/concept/N>.
<obj/concept/N> a E73_Information_Object; P67_refers_to <place>.

Here <obj/concept/N> is a parasitic node.

[Vladimir Alexiev]

I wrote a XQuery script that simplifies the ecrm-current.owl file by removing some OWL constructs.

It always keeps owl:inverseOf and owl:SymmetricProperty (self-inverses): they are an innate part of CRM.

Parameter keep= gives a comma-separated list of other features to keep:

- transitive: owl:TransitiveProperty

- restriction: owl:Restriction (blank-node subClassOf)

- functional: owl:FunctionalProperty, owl:InverseFunctionalProperty

- disjoint: owl:disjointWith

 

So this can script can make "ECRM profiles", which use only a subset of OWL constructs.

 

 

Why did we need this in ResearchSpace?

Because the ECRM owl:Restrictions add 20-25% more statements that are useless for us.

(I'd appreciate pointers to any system that uses them).

 

The CRM class hierarchy is quite deep, and each of these restrictions is propagated through it.

We have these counts of rdf:type statements for 115k British Museum objects:

_:nodeXX	34675445		41.2%
owl:Thing	5423480		6.4%
CRM classes	43325284		51.5%
crm:E1_CRM_Entity	5423480
crm:E77_Persistent_Item	3869228
crm:E70_Thing	3800112
crm:E72_Legal_Object	3688546
crm:E71_Man-Made_Thing	3681210
crm:E28_Conceptual_Object	2932619

…..

So we’ll save 34.6M statementns. (Next I’ll be looking at a way to eliminate the useless owl:Thing statements).

In ResearchSpace we use “transitive” (with a few added statemetns that I believe were forgotten) but not restriction, functional or disjoint.

 

 

Apart from the practical considerations above, ECRM makes "ontological overcommitments" beoynd the CRM standard.

E.g. it says (in Manchester syntax):

 

Class: ecrm:E72_Legal_Object

    SubClassOf:

        ecrm:P104_is_subject_to some ecrm:E30_Right,

        ecrm:P105_right_held_by some ecrm:E39_Actor,

        ecrm:E70_Thing

 

Which means: Legal_Object is not only a subclass of Thing (as per CRM standard), but there must be some Right and Actor that it is related to.

However, such objects may not be present in cases of missing information, so what good is that assertion?

 

 

Last summer Martin Doerr asked if I can extend the CRM RDFS version to include inverses, being an innate part of CRM.

Such version is attached here (ecrm-inverses.owl), made from the ECRM version with my simplification script.

(The xmlns and xml:base at the beginning should be changed to the agreed CRM namespace.)

 

 

The CRM community will benefit *greatly* from a single RDF definition of CRM.

This will not only eliminate effort duplication by the different maintainers, but will remove doubt in the community which version to use.

 

The unified spelling of property and class names adopted by the CRM SIG on Nov 20 is an important step in that direction

- I am glad the ECRM spelling was agreed, since it'd have been quite hard for us to change the ResearchSpace code base to use a different spelling

- the new RDFS release http://cidoc-crm.org/rdfs/cidoc_crm_v5.0.4_official_release.rdfs uses that spelling

 

If the two groups want to collaborate, maybe the best approach is:

- maintain the unified ontology in Protégé

- export an OWL version from Protégé

- use the simplification script to make “application profiles” as described above

 

Below are some next steps. Who can help?

 

- diff the two versions to find any discrepancies

-- This can be done with the Protégé plugin. I started doing it once, but dropped it after 10 min…

-- There is OWL Patch: http://owl.cs.manchester.ac.uk/patch/

However, I tried it from the commandline and got this:

> curl "http://owl.cs.manchester.ac.uk/patch/diff.php?a=http://cidoc-crm.org/rdfs/cidoc_crm_v5.0.4_official_release.rdfs&b=http://erlangen-crm.org/onto/ecrm/ecrm_current.owl"

Sorry, can't diff!

 

- add an official namespace, something like http://cidoc-crm.org/ns# or http://cidoc-crm.org/ns/

  ResearchSpace will be willing to adopt this namespace *if* agreed by Jan 15.

  After that date we’ll be loading 1.5M BM objects (estimated 2.076B statements)

 

- take the multilingual labels from RDFS.

  The ECRM guys prefer the prop/class numbers to be included in the labels, so this needs to be argued

 

- take the longer rdfs:comments from ECRM.

  Optionally, split into skos:scopeNote vs skos:example

 

- take skos:notation from my email 8-Aug-2012. I posted a script that generates statements like:

   ecrm:P91i_is_unit_of rdfs:label "P91 is unit of"; skos:notation "P91i"

 

Best! Vladimir