Issue 212: P62 needs a parent and a sibling

Posted by Vladimir Alexiev 5/07/2012

There's a variety of 'aboutness' properties of Conceptual objects, a total of 5.
They are subproperties of P67,and in particular 2 more specific sub-properties are used often: P129, P138.

In contrast, there's only 1 'aboutness' property of Physical objects: P62. It is a shortcut of P138 through E36_Visual_Item.

So looking at the property hierarchy
http://personal.sirma.bg/vladimir/crm/entity_list_cleaned.html#property-hierarchy 
(scroll 2p down)
and putting the Conceptual and Physical (domain) side by side,
we see these gaps, denoted ???:

Conceptual Physical 
P67_refers_to ??? 
- P129_is_about ??? 
- P138_represents P62_depicts

In the BM database there are many instances where a physical object refers to something (person, event) or is about something, but the nature of this reference is not visual. 
In such cases we'd like to use physical analogs of P67,P129 but currently we need to create a "parasitic" conceptual node so as to satisfy the Domain restriction.

(Or let the physical object also be a conceptual object,with a P128_carries self-loop, a practice I've been criticised for).

So I think it would be useful to create a parent and sibling of P62,that can serve as shortcuts of P67 and P129 respectively.
 

Posted by Stephen Stead on 5/07/2012 

Vladimir 
Just trying to understand the problem a little more. Could you give a couple of examples of the physical object being about a person or event where the "aboutness" is not a depiction?

Without specific examples my suspicion is that there is a conceptual object that is "about" something and that is being carried by the physical object but I want to be sure that this covers the cases that you are seeing.
 

Posted by Mathew Stiff on 5/07/2012

For example, a gravestone carrying an epitaph 
 

Posted by Stephen Stead on 5/07/2012

That is clearly a conceptual object being carried by the physical object
 

Posted by Sebastian Rahtz on 5/07/2012

| Just trying to understand the problem a little more. Could you give a couple of examples 
| of the physical object being about a person or event where the "aboutness" is not a depiction? 

a blue plaque. eg http://en.wikipedia.org/wiki/File:Dickens-plaque-tavistock.jpg

its about both Dickens and the building to which its attached.
 

Posted by Stephen Stead on 05/07/2012

Yes this is another inscription (conceptual object) that is carried on the physical object (the plague). It is the conceptual object that has the "aboutness" not the plaque.
 

Posted by Mathew Stiff on 6/07/2012

I agree with Steve. I've struggled to think of any examples that don't constitute the physical object acting as a carrier for a conceptual object. I know the example I suggested for Steve's thinking was a bit obvious, but unless any of Vladimir's examples are radically different then the model seems to be robust in this area.
 

Posted by Vladimir Alexiev 9/07/2012

Matthew> I agree with Steve. I've struggled to think of any examples that don't constitute the physical object acting as a carrier for a conceptual object.

Matthew and Steve, I think you've missed the point: 
I did not say I have a case with *only* a shortcut "aboutness" property from Physical, where a longcut path through Conceptual could not exist.
I said that often it's useful to use a shortcut, without having to create a longcut.

Can you give any example of a physical object having P62_depicts that would preclude the existence of a conceptual object (E36 Visual Item) having P138_represents towards the same target?
If you cannot, what is your justification for having P62_depicts, but not having the properties denoted "???" in my original email?
 

Posted by Vladimir Alexiev 9/07/2012

| Steve is right to ask for some examples 

Yourself and Sebastian gave a couple.
Here's another: drawing of an actress (P138_represents), where the BM data also mentions the play she's performing (P67_refers_to) and the script writer (P67_refers_to).

Josh, can you give some more examples from the BM data?
Examples of P67_refers_to or P129_is_about that are not P138_represents.
 

Posted by Stephen Stead on 9/07/2012

I think the simple answer is 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.
 

Posted by Stephen Stead on 9/07/2012

The example of the drawing of an actress having further details in unstructured data would need to have a series of intermediary nodes introduced to complete the path to the script writer from the drawing. 
There is no conceivable shortcut that could provide a link directly. What is interesting is the link between the BM object record (a conceptual object) and the script writer which also has a number of hidden FRBRoo events (for instance the F27 Work Conception).
 

Posted by Vladimir Alexiev on 9/7/2012

| I think the simple answer is we saw P62 used in actual data models.
| We have not seen the others and so had no justification for creating them.

Are the examples provided sufficient justification?

| The example of the drawing of an actress having further details in unstructured 
| data would need to have a series of intermediary nodes introduced to complete 
| the path to the script writer from the drawing...
| FRBRoo events (for instance the F27 Work Conception...

The structured BM data (table Associated Person) says the physical object is somehow related to the script writer (who comes from a thesaurus). We cannot create a precise path involving FRBRoo because the relation is explaned in a mere note.

| There is no conceivable shortcut that could provide a link directly.

Sure there is: P67a_refers_to that's just like P67 but has physical domain.
We're currently doing:

P62_depicts 

P128_carries .
P67_refers_to 
.

We'd like to get rid of the parasitic (empty) node and just do this:

P62_depicts 

P67a_refers_to 

Posted by Stephen Stead on 9/07/2012

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. 
This is the same as rendering a person as a scriptwriter or architect. They were not born as scriptwriters or archtitects it was a role they played in particular event(s).

Posted by Matthew Stiff on 9/07/2012

Interesting one, this. 

Truth is, if you look at SPECTRUM 4.0 this is a widely used standard (and I am not defending it!) that seems to model it in the way that Vladimir describes. Taking the example of a blue plaque commemorating, say, a battle, SPECTRUM would record the battle using any of the following:

1. Associated Event Name (and Associated Event Name Type)
2. Associated Activity
3. Associated Event Date
4. Associated Event Organisation
5. Associated Event People
6. Associated Event Person
7. Associated Event Place
8. Association Type

The last of these would seem to cover "commemorates". Key thing is that this is part of the Object History and Association Information Group and is clearly linked to the physical item of documentation rather than any conceptual object associated with it. In the case of a Blue Plaque this actually makes sense since the decision to have an object commemorating an event or person arises before a decision is made as to what the plaque is actually going to say.

The information groups in SPECTRUM do not seem to have been radically changed since version 2.0 which I think is a shame - The groupings are not very robust - but we do seem to have an example in practice that supports what Vladimir is saying. I would not be surprised if this is actually implemented in commercial collections management software. 

Posted by Matthew Stiff on 9/07/2012

....although I freely admit that the blue plaque is itself a conceptual object until it is actually made! 

Posted by Vladimir Alexiev on 10/07/2012 

| 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! 

Posted by Martin Doerr on 10/07/2012 

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://old.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.