W3C home > Mailing lists > Public > public-swbp-wg@w3.org > May 2004

Re: [OEP] Draft of a note on n-ary relations

From: Fabien Gandon <Fabien.Gandon@sophia.inria.fr>
Date: Wed, 26 May 2004 11:28:30 +0200
Message-ID: <40B4633E.80302@sophia.inria.fr>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:38 UTC