[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