[Crm-sig] reified association vs sub-event

martin martin at ics.forth.gr
Wed Oct 15 21:57:20 EEST 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 
to introduce classes for all 3ary properties by a standard naming 
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,




On 15/10/2014 6:41 ??, Richard Light wrote:
> 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 onhttp://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*
> _______________________________________________
> 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           |

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20141015/5ce813a8/attachment-0001.html>

More information about the Crm-sig mailing list