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
[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 |
--------------------------------------------------------------
_______________________________________________
Crm-sig mailing list
[email protected]
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: [email protected]
URL: http://www.ics.forth.gr/isl
------------------------------------------------------------------------
