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
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
*Richard Light*
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
--------------------------------------------------------------
