Issue 266: Reified association vs sub-event

Posted by Richard Light   on 15/10/2014

Vladimir,

I can't answer your question on the openness or closed-ness of the two approaches.  However, that won't stop me from commenting, since no-one else has.

This is an example of the famous "property of a property" issue, which has proved to be a challenge for the CRM in an RDF context.  In the original [abstract] object-oriented CRM data model, we cheerfully allow properties to have properties [1], and this is an accepted way, for example, to qualify the role which a person plays in relation to an activity.  However, the way in which this more precise role is normally specified in practice (which the CRM document goes on to give examples of) is by declaring the more specific property to be a subproperty of the original property.

If you do this, the subproperty simply takes the place of the original more generic property in an RDF expression of the statement, and the result is a meaningful RDF triple.  If, instead, you try to express "property of a property" as RDF, you find that you are trying to construct a triple with a predicate as its object; something RDF does not allow.

As I understand it, the BM tried the "subproperty" strategy first, and found that it led to an explosion in the size of their data model, and didn't sit well with their actual data, e.g. their roles termlist.  So they investigated an alternative approach and came up with the "reified association" strategy.  It took me a while to get my head around this, not least because of diagrams like the one at the top of p.15 of the Primer [2], where the arc in red is clearly nonsense in a simplistic RDF-modelling sense.  However, I now believe.

This particular problem has exercised me for some years.  In our XML-based Modes system (which harks back to the original MDA Data Standard in its structuring approach), we routinely record multiple people as being associated with an Activity, each playing distinct role(s).  We don't quite get it right there, from a strictly logical PoV:

<Production>
<Person><Role>designer</Role><Name>Light, R.B.</Name></Person>
<Person><Role>engraver</Role><Name>Smith, J.</Name></Person>
...

The point is that each person will play many roles in their life, and the role that is recorded here is only meaningful in the context of this particular activity.  So the role isn't a property of the person: it's a property of the person-playing-a-role.  So, my suggestion is that we create a new class RolePlayer, which could be defined as "one or more Actors playing one or more specified Roles in relation to an Activity".  Then we could model what we are trying to say, elegantly and precisely.

The trouble with the "sub-event" strategy is in my view two-fold: it is creating sub-events where there are none, simply to address a modelling problem with people having multiple roles; and it is falsely associating the role with the sub-event when that role is actually a property of the person involved in the sub-event.

Apologies if this has all been discussed before.  It does seem like rather a basic point, and I do vaguely remember the concept of "RolePlayer" from the CIDOC Relational Data Model days.

Richard

[1] "Properties may themselves have properties that relate to other classes", CRM Reference v5.1.2, p.ix
[2] http://www.cidoc-crm.org/docs/CRMPrimer_v1.1.pdf

Posted by Martin 15/10/2014

Dear All,

The issue has been discussed in CRM-SIG in Heraklion. If we need 3ary relations, because
the vocabularies for these roles are not fixed at schema definition time, the only solution
is to introduce an RDF class for the relationship. It's no problem in ER, ooER and other metamodels.

Then we can play around with solutions, in which we regard this class being an E13, a reiification, a subevent or whatever, and in no case RDF will recognize the semantics.
The utility of reusing or abusing classes like E13 is questionable, in particular if we want to use
E13 to describe epistemological situations distinct from the default authors of the knowledge base.

The cleanest way appears to be, following the last discussion/proposal in CRM-SIG,
to introduce classes for all 3ary properties by a standard naming convention,
such as "R14Node_carried_out_by" , and declare by OWL rules the inferences based on
that, in particular, if roles form strict IsA hierarchies. Then, R14 is infered from R14Node by rule,
etc.

Opinions?

Best,

Martin

Posted by Carlo Meghini      on 16/10/2014

> 4. In RDF it is possible to make assertions about an RDF statement by using the RDF reification mechanism. RDF reification is generally considered to be pretty bad (a reified statement does not even entail the original statement).
>
Well, I perceive this general sense of distaste for RDF reification, but I must confess I do not understand it.

By reifying a triple (s p o) and assigning a URI u to it, one merely says that in the world there exists a linguistic resource that is a statement and is identified by u. Why should this imply that the statement is true? As we all know, the world is full of statements that are not necessarily true (like for instance this message), and we talk about these statements using names for them. Reification just supports this.

If one wants to say that the triple, in addition to exist as a resource in its own right, also happens to be true, then one just asserts the triple (s p o) by adding it to the graph. But this is a separate operation. It would be in my opinion wrong to assert the triple just because it exists.

Carlo

Posted by Vladimiri on 16/10/2014Richard> the famous "property of a property" issue, which has proved to be a challenge for the CRM in an RDF context.

This and similar issues are of course not unique to CRM, and various approaches have been adopted in the RDF community.
See http://www.w3.org/TR/swbp-n-aryRelations/.
Approaches include:
- domain-specific mechanisms, e.g.
-- skosxl:Label reifies a label in its own node
-- PROV has both direct roles, and "qualified" (i.e. reified) roles:
  http://www.w3.org/TR/prov-o/#description-qualified-terms
  http://www.w3.org/TR/prov-o/#qualified-terms-figure
- statement reification (rdf:Statement),
- property reification vocabulary (that allows to express any domain-specific reification in a machine-accessible way)
  http://smiy.sourceforge.net/prv/spec/propertyreification.html
- or named graphs.
These methods allow you to add any extra data (attributes, provenance, etc) to relations.
I would suggest that before we adopt any modeling decision, we should study these existing practices.

See this paper "Types and Annotations for CIDOC CRM Properties" at http://www.ontotext.com/research-publications/?yr=2012
where I analyze some of the approaches in relation to CRM.

The already quoted https://confluence.ontotext.com/display/ResearchSpace/BM+Association+Map...
shows the actual patterns used in the BM mapping.

E13_Attribute_Assignment is rather fundamental to CRM because it's the mother of all long-paths (e.g. has_dimension is a shortcut, Measurement is a long-path).
It almost matches RDF reification (rdf:Statement with rdf:subject, rdf:object and rdf:predicate),
but it doesn’t have a way to point to the property (rdf:predicate).
Ergo the need for its extension bmo:EX_Association and bmo:PX_property.

Martin once made what I think is a productive remark, but it hasn't been taken seriously and investigated:
use E13_Attribute_Assignment.P2_has_type to hold the property.
Of course, this will make properties be E55_Type.

BTW, MARC Relators are defined in this way: they are both skos:Concept and owl:ObjectProperty.
E.g. see http://id.loc.gov/vocabulary/relators/abr.nt:
  <http://id.loc.gov/vocabulary/relators/abr> a owl:ObjectProperty.
    rdfs:subPropertyOf <http://id.loc.gov/vocabulary/relators/role>, <http://purl.org/dc/elements/1.1/contributor>.

I still can't make up my mind whether that’s an awful transgression or a neat trick.
Simon, what do you think?

Simon> Using reified associations labelled with concepts from a version of SKOS supporting hierarchical relationships
> does not automatically entail that hierarchy for the associations

Yes of course, the consequent facts would have to be asserted separately.
But do you see more troubles with such approach than that?

> declaring the more specific property to be a subproperty of the original property. 
> BM tried the "subproperty" strategy first, and found that it led to an explosion in the size of their data model,
> and didn't sit well with their actual data, e.g. their roles termlist

Yes, this has the following problems:
- huge ontology compared to the core it uses
- volatile ontology: every time role terms are modified, so needs to be the ontology
- you can't say more about the role instance (e.g. who when asserted it is so; probability/uncertainty, etc) without turning again to Reification
- while role instances are reflected in CRM (through subproperty inference), Reified statements *are not*.
  This means that a model using Reification over extension properties *is not* (fully) a CRM Extension as defined in the standard.

Richard> The trouble with the "sub-event" strategy is in my view two-fold:
> it is creating sub-events where there are none, simply to address a modelling problem with people having multiple roles;
> and it is falsely associating the role with the sub-event when that role is actually a property of the person involved in the sub-event.

That's not quite correct.
- The ability of CRM to always breakdown an event into subevents is quite powerful.
  E.g. you may consider "engraver", "printer" and "publisher" as 3 roles of the same production event,
  but I may very naturally consider them as 3 subevents of the production: "engraving", "printing" and "publishing".
  Then the standard carried_out_by is enough: the person who carried out the "engraving" is clearly the "engraver" of that CHO (object).
  No falsehood here.
- On the other hand, the BM has gone too far into breaking up events,
  since unfortunately in their database there's no info correlating the various fields of events (e.g. facts about production).
  So the BM mapping emits every fact in its own subevent: something that I don't think other museums should follow.
- And in some cases I agree the breaking up into subevents goes too far.
  E.g. a Change of Ownership where one owner got money (sold) but the other did not (donated).
  If that's modeled as subevents, shouldn't we also model fake (ideal) parts of the object that the two people owned before the transaction?

Martin> I think we should stop discussing half-hearted work-around as if the problem would not exist.

I agree, it's an important problem that has connections to one of the most important CRM constructs:
shortcuts vs long-paths.

Martin> introduce classes for all 3ary properties by a standard naming convention,
> such as "R14Node_carried_out_by"

Specific classes have both advantages and disadvanteges compared to a general class like E13.
These should be studied carefully...
I tend more towards a generic solution (currently that is).

Maria> http://www.ics.forth.gr/isl/CRMext/Roles.pdf

In "Solution 2", an important question is where do we put extra info: "PC14 carried out by" or "E7 Activity"

Carlo> I perceive this general sense of distaste for RDF reification, but I must confess I do not understand it.

Me neither. I use it e.g. in Getty to represent historic info on relations:
http://vocab.getty.edu/doc/#Applying_to_Relations_and_Place_Types
Maybe because it's non-economical:
If oen already has a domain-specific class that reifies the relation, one should use that.
But if there's no such class, I think rdf:Statement is ok.

Simon> In OWL 2 it is possible to add annotations to a property assertion axiom.
> These annotations are only about the particular act of assertion, rather than what is being asserted.

These are isomorphic to rdf:Statement and I still don't quite grok the difference.
Guess it's the same difference as between data/object properties, and annotation properties.
But rdfs:label is an annotation property, yet the whole world uses it for labels of objects.

Cheers!

Posted by Karl Grossner   on 17/10/2014

This thread spurred me to finally revisit some work I did in 2010 that departed from both CIDOC and DOLCE by reifying a participated relation to get at roles among other things. Just wrote a blog post about it, with links and figures, and plan to convert the model soon from FOL and an object-relational schema to something more appropriate for 2014, like OWL2.  (http://kgeographer.com/wp/stuff1a/)

My (probably naive) view is that reification enables sensical open world systems, by permitting attribution of individual statements. Or if open world is strictly AAA, without identifying who Anyone is, what use would it be?
 

Posted by    Karl Grossner   on 18/10/2014

> Without sounding polemic, I’d like to comment on the “something more
> appropriate for 2014”. Please note that I am a peaceful guy

thank goodness, me too. ;^)

> and, on top of that, a great fan of description logics,
> which I have been using for twenty years (alas).
> I think the appropriateness of logic is not time-related, but rather
> purpose-related.

“something more appropriate for 2014” was an ironic dig at myself for publishing my modeling patterns written in FOL, a form few can read, and not directly usable in systems -- as opposed to RDFS and OWL, which may be sufficient, and are accessible to more colleagues in the DH projects I work on. I love logic and the promise of inference and enthusiastically support analysis of CRM and its potentially more formal expression! I was 'not up to DL' at the time -- not critical of it.

> In setting off for a logical analysis of the CRM, my
> purpose is not implementation but rather understanding. My first
> understanding from the yet incomplete exercise, is that no OWL
> implementation is going to be equivalent to the CRM. So, if one is
> interested in understanding the CRM, he should NOT look at an OWL
> implementation. He may look at the current specs, but, if in need of some
> formal account, I would not know where to look.
>

I see now that you and Martin had a paper on CRM in FOL. I had missed this, and wasn't commenting on the worth of the effort at all! The representation of my own ontology design patterns in FOL gave me understanding (and clarified still unanswered dilemmas). Ultimately I'm very attuned to implementation right now.

> And then there are extensions: the CRM is being extended in a number of ways
> and I believe it is better to analyse these extensions in the neutral
> language of logic, entirely free of any expressive limitations.

I guess I agree, since that's what I did for my own. They were/are more extensions of DOLCE, but CRM was always in the mix.

I will read the paper and follow this work with great interest!