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

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 88Received 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
*