[Crm-sig] reified association vs sub-event

[Richard Light]

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

On 14/10/2014 17:44, Vladimir Alexiev wrote:
> Hi everyone!
> (This is particularly for Martin and Dominic, but comments from everyone are welcome)
>
> The BM mapping uses two patterns to express the relation of an entity (typically person) to an event:
>
> 1. use reification over the relation (bmo:EX_Association is a subclass of CRM Attribute Assignment):
>    https://confluence.ontotext.com/display/ResearchSpace/BM+Association+Mapping+v2#BMAssociationMappingv2-TranslatedCodeInReifiedAssociation
>    Illustrated on http://www.cidoc-crm.org/docs/CRMPrimer_v1.1.pdf   p.15
>
> 2. make sub-event (e.g. Production part) and put the relation type there:
>    https://confluence.ontotext.com/display/ResearchSpace/BM+Association+Mapping+v2#BMAssociationMappingv2-TranslatedCodeinSubEvents
>    This is not well illustrated in the CRMPrimer:
>    p17 shows a sole event part, and p18 shows two parts but without P2_has_type.
>    But you get the idea
>
> 2 is used more often in the mapping (see the page above).
> 1 is used less often: for Influenced/Motivated relations (not for P14 carried out by), and to express uncertainty.
> Specifically: Acquired Through (contributor), Probably/Unlikely Produced By, (production) Influenced By, Production Motivated By, Probably Produced At, Made For Place
>
> Martin and Dominic have said that 2 is more open-world while 1 is more close-world.
> Could you please explain this to me?
> It's very important for me as I move closer to Getty ULAN and CONA modeling.
>
> Thanks in advance!
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>

-- 
*Richard Light*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20141015/70324fd3/attachment.html>