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

Dan, all

Dan Connolly wrote:

> On Thu, 2004-05-13 at 10:12, Alan Rector wrote:
> [...]
> > * I think CurriedFunctions are different and would prefer to avoid them in a simple primer
> fair enough...
> > * The argument list is a common programming trick - e.g. functions that deliver tuples -
> > but I think distorts the spirit of either RDF or OWL.
> Huh? Distorts the spirit?
> It's quite straightforward and it works well.

See below under explicitness.  I think it makes the meaning much less clear and extension much more difficult.
(unless of course, one of the values really is a list, but that's not the case we are considering)

> >   For OWL it has the added
> > disadvantage of moving immediately to OWL full
> Really? I don't think so. Can you explain how the use of a list as
> the subject of a property moves to OWL full?

Oops - what it does move us is out of the things currently supported by the common reasoners, FaCT &  Racer.
I sometimes mistake the capabilities of existing tools for the specification of OWL-DL.  This may be fixed relatively soon,
but is certainly true now.

> >  and - I think - requiring a data type property to hold the list for
> > what is otherwise semantically an object property. (If I am wrong on this, somebody
> > please correct me.)
> Maybe I'll check with a tool or something.
> >   It also leaves the semantics of the different arguments implicit whereas any
> > of the other mechanisms make them more explicit.
> More explicit? I don't understand what you mean by that.
> > I wouldn't oppose including it, but I would want those  'health warnings' attached.

Simply that in the list, the roles of the arguments are indicated by position rather than by being labelled by a property.  To somebody reading the expression, it isn't necessarily obvious which argument has which role.  Likewise, it much harder to extend for programming.  If the role of each argument is indicated by a separate property, then additional roles can be added by adding additional properties without changing anything else. If they have to be added to a list, it is likely to require much more complications - e.g. there might have been a length limit.

Also, in the list case, it is harder to see how semantics of subsumption works.  When do two lists subsume each other?  I'd need one of the rdf:logic folk to check that out.  I presume super-lists entail sublists, but I am not sure. I do suspect it will be some time before reasoners catch up and support it.

Similarly, if the graph for a value needs to be extended , the result is a single graph.  In the list form, if a value needs to be extended, we have a graph inside a list.  Possible but messy.  Again, given the split between object properties and datatype properties in OWL, I think this is going to be nasty.

I am prepared to be convinced  of the feasibility by some well worked out examples, but the more I think about it at my current understanding of what would be involved, the more sceptical I am, except for the case in which the value really is naturally a list (or some other complex datatype) - which is clearly not what this note is about.

Even if it is feasible, when would this approach have an advantage?  Why add the complication of a list datatype when we can just add ordinary properties, object or datatype as required?



> I don't see how using lists puts anybodys health at risk. ;-)
> Please do include it.
> [...]
> --
> Dan Connolly, W3C
> see you at the WWW2004 in NY 15-21 May?

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

Received on Friday, 14 May 2004 05:21:10 UTC