[Top] [All Lists]

Re: [ontolog-forum] predicates in RDF

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Danny Ayers" <danny.ayers@xxxxxxxxx>
Date: Thu, 3 Jan 2008 15:12:34 +0100
Message-id: <1f2ed5cd0801030612o55e7dfe6o72afddc2b3521ec5@xxxxxxxxxxxxxx>
On 02/01/2008, Patrick Cassidy <pat@xxxxxxxxx> wrote:
> Just a little off-topic "cri de coeur" about the naming of relations:
> [Chris Menzel said]
> >
> > But why?  "creator" in that example from the RDF documentation is
> > simply
> > short for "is the creator of", which corresponds almost exactly to the
> > definition of "predicate" that you yourself provided.
> >
> Actually, in that document it is short for "has creator", which has the
> opposite polarity from "is the creator of".
> This is an extremely easy-to-make misinterpretation when simple nouns are
> used to name relations: the polarity could logically be defined either way,
> and different people use it in different ways.
> I really, really wish people would just stop using simple nouns to express
> relations, and always use a verbal form like "isTheCreatorOf" or
> "hasCreator" or "is_the_mother_of" because when a simple noun is used there
> is time wasted trying to remember or recheck just what the intended polarity
> was, and a significant probability that it will be used incorrectly.    (01)

Had a convention appeared early on for the use of nouns with a
consistent polarity, then the simple noun approach described here
would make a lot of sense:    (02)

http://esw.w3.org/topic/RoleNoun    (03)

But as it stands, I'm not sure it's viable in the general case for the
reasons you give. I certainly get confused : I don't know whether it's
a linguistic pattern or just habit - "creator" seems clear to me, but
"father" could work either way.    (04)

There's an additional problem with predicate naming when the implicit
inverse is brought into the picture. timbl suggests
(http://dig.csail.mit.edu/breadcrumbs/node/72) we only need a name in
one direction, a label for the predicate is adequate in the other. But
I'm pretty sure the direction suggested by the Role Noun pattern won't
be the obvious one in all cases.    (05)

For what it's worth, when working with RDF I generally assume the appearance of:    (06)

<subject> <predicate> <object>    (07)

in a graph (RDF Model) means:    (08)

<subject> <predicate> <object>    (09)

- appears in that model!    (010)

This is enough for a lot of useful operations (e.g. SPARQL querying).
The rules for statement equivalence are easy enough to overlay, as are
those of RDFS and OWL (with caveats around the DL constraints).    (011)

The things can also be viewed as Coddesque (binary) relations, but
from a pragmatic viewpoint that's just another arbitrary association
of the three parts to roles. Similarly the structure of the Web can be
overlayed - <subject> and <object> are resources in the sense of
WebArch (http://www.w3.org/TR/webarch/), and <predicate> is a
(possibly typed) link between them. I believe the RDF MT is consistent
with this view of WebArch, at least if it isn't I've not noticed any
undesirable side effects. (Ok, there seem to be some weird
disconnects, but no obvious contradictions).    (012)

I am not a logician, and don't need to be, now Pat et al have got that
stuff in place. The naive approach above seems to work fine as long as
the open world assumption is borne in mind (not too much, in practice
most of the time you're working against a locally-closed world), and
avoid any tendency to slip into object-oriented programming style (can
be tricky, when using the stuff in an OO language)...and for that
matter natural language linguistics.    (013)

Danny.    (014)

--     (015)

http://dannyayers.com    (016)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (017)

<Prev in Thread] Current Thread [Next in Thread>