- From: Fabien Gandon <Fabien.Gandon@sophia.inria.fr>
- Date: Wed, 26 May 2004 11:28:30 +0200
- To: public-swbp-wg@w3.org
Pat Hayes a écrit :
> Yes. I mentioned it only to emphasize that there are many options. I was
> thinking of something like the rdf container vocabulary but using
> special named subproperties of the original property as the container
> membership functions, rather than relating the container itself to the
> property, so the overall pattern for three arguments would be
>
> x P1 a
> x P2 b
> x P3 c
> P1 subProp P
> P2 subProp P
> p3 subProp P
Hello,
I am trying to catch-up with my e-mails and I really enjoyed reading the
design pattern on the n-ary relations and the discussions that followed.
Since the design patterns should capture an objective design rationale
for choosing one option over another I tried to understand the pros/cons
of the three proposals so far to represent n-ary relations when all we
have are binary properties:
- proposal 1 : the reification of the fact that a n-ary relation holds
by introducing a concept type for this fact and a set of properties
for the roles; this first approach encompasses both patterns of the
initial document of Natasha.
- proposal 2 : turn one or both arguments into a list of arguments;
(compared to the initial patterns of Natasha, it like the first
pattern i.e. one of the individuals in the relationship is
distinguished from others)
- proposal 3 : introduce a (dummy) binary property representing the
n-ary relation and binary sub-properties specialising it for each
role; (compared to the initial patterns of Natasha, it like the first
pattern i.e. one of the individuals in the relationship is
distinguished from others)
I understand that proposal 1 is not "reifying" the n-ary relation but
the events of this relation holding. It also transfers part of the
hierarchy of properties to the hierarchy of concepts. Any way we are
looking for a hack since there is no direct way to model n-ary relations.
I am not completely clear on proposal 2. In particular, can we still
constrain the roles/signature of the n-ary relation, i.e. can I describe
a signature like child_of(person, (man, woman)) and can this signature
be refined in the sub-relations, especially the list part?
Also, what happens when we want to model the inverse relations? I don’t
see an easy way to do that since most of the roles are made implicit by
the list structure.
Finally, unless I completely missed the point, proposal 3 seems to be
only practical when we are dealing with a functional relation. Indeed,
if we have
P1 subPropertyOf P
P2 subPropertyOf P
P3 subPropertyOf P
and
x P1 a
x P2 b
x P3 c
(which represents (P,x,a,b,c) )
and
x P1 d
x P2 e
x P3 f
(which represents (P,x,d,e,f) )
then when once all these triples are loaded we can no longer know if we
had (P,x,a,b,c) or (P,x,d,b,c) or (P,x,a,b,f) or...
Still for a functional relation like child_of(person, (man, woman)) this
approach works and you can also define inverse properties.
Fabien
--
"We British have so much in common with the Americans
except, of course, language." -- Oscar Wilde.
____________
|__ _ |_ http://www-sop.inria.fr/acacia/personnel/Fabien.Gandon/
| (_||_) INRIA Sophia Antipolis - ph# (33)(0)4 92 38 77 88
Received on Wednesday, 26 May 2004 05:29:30 UTC