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
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
*Richard Light*
