[Crm-sig] reified association vs sub-event

Maria Theodoridou maria at ics.forth.gr
Thu Oct 16 12:54:26 EEST 2014


Dear All,

In http://www.ics.forth.gr/isl/CRMext/Roles.pdf
I tried to present schematically three options for dealing with the 
"property of a property" issue in rdf.

What Martin calls "R14Node_carried_out_by" is "PC14 carried out by" in 
my figures.

Best,
Maria


On 15/10/2014 9:57 μμ, martin wrote:
> 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
>
> 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            |
> --------------------------------------------------------------
>
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig


-- 
------------------------------------------------------------------------
Maria Theodoridou
R & D Engineer

Information Systems Laboratory & Centre for Cultural Informatics
Institute of Computer Science
Foundation of Research and Technology - Hellas (FORTH)
Science and Technology Park of Crete
Vassilika Vouton, P.O.Box 1385, GR-711 10 Heraklion, Crete, Greece

Tel.: +30-2810-391731  Fax:  +30-2810-391638  E-mail: maria at ics.forth.gr
URL: http://www.ics.forth.gr/isl
------------------------------------------------------------------------

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


More information about the Crm-sig mailing list