- From: Alan Rector <rector@cs.man.ac.uk>
- Date: Wed, 08 Dec 2004 08:45:08 +0000
- To: Guus Schreiber <schreiber@cs.vu.nl>
- CC: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, public-swbp-wg@w3.org, joint-committee@daml.org
All Guus has said it more clearly than I could of. The issue is modelling rather than logical structure. Another point is that it is common in the evolution of an ontology to start by using a simple property plus binary relation and then move to pattern 1 - re-representing the property as a class - as it becomes clear that an n-ary relation is needed in at least some cases. This is a common enough operation that we are implementing a "wizard" to make it easier, either for a single property or a whole group of properties. Often it happens that there is a large set of properties/cases that one wishes to model consistently. In this case, if any of the cases needs to be modelled with pattern 1, then they all do. Otherwise, modellers become hopeless confused as to which conceptual relationship is to be modelled in which way. Finally, version 1 matches to ontological notion of a "quality" and "quality space" as in Guarino and Welty's work, whereas this consideration is not relevant to pattern 2. Regards Alan Guus Schreiber wrote: > > Peter F. Patel-Schneider wrote: > > > I just read the N-ary relations draft and I am somewhat confused as to why > > it has the two representation patterns. I don't see that the two patterns > > are different in any substantial way as the only difference between them is > > the direction of one arrow. This difference may matter in some formalisms > > but doesn't in RDF/RDFS (as they are too weak to notice much difference) or > > OWL (as it has the inverse construct). > > > > So, my question is why maintain the two different representation patterns? > > Peter, thanks very much for the comment. > > Natasha and Alan are probably the best people to answer this, but I will > give you my reading of the difference. > > The distinction is of a modelling nature. In Pattern 1 you create a > helper relation (represented as a class) which has (in most cases) no > name in the domain of interest. In Pattern 2 the relation class has some > name in the domain, typically a noun representing some activity (e.g. > purchase, enrolment, transaction, subscription). I think this is an > important difference of which developers should be aware. In particular, > in the case of pattern 1 a an engineer might find it weird to construct > a name from the blue, and it may help her/him to know it's actually good > practice. The resulting representation is very similar, I agree. Maybe > we should make this point more clear in the text. > > Hope this helps, > Guus > > Guus > > > > > Peter F. Patel-Schneider > > Bell Labs Research > > > > -- > Free University Amsterdam, Computer Science > De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands > Tel: +31 20 444 7739/7718 > E-mail: schreiber@cs.vu.nl > Home page: http://www.cs.vu.nl/~guus/ -- Alan L Rector Professor of Medical Informatics Department of Computer Science University of Manchester Manchester M13 9PL, UK TEL: +44-161-275-6188/6149/7183 FAX: +44-161-275-6236/6204 Room: 2.88a, Kilburn Building email: rector@cs.man.ac.uk web: www.cs.man.ac.uk/mig www.opengalen.org www.clinical-escience.org www.co-ode.org
Received on Wednesday, 8 December 2004 09:33:03 UTC