W3C home > Mailing lists > Public > www-rdf-interest@w3.org > July 2002

RE: Associations in RDF

From: Sampo Syreeni <decoy@iki.fi>
Date: Mon, 22 Jul 2002 13:06:44 +0300 (EEST)
To: Bill de hÓra <dehora@eircom.net>
cc: <www-rdf-interest@w3.org>
Message-ID: <Pine.SOL.4.30.0207221206400.6728-100000@kruuna.Helsinki.FI>

On 2002-07-21, Bill de hÓra uttered to www-rdf-interest@w3.org:

>Any example I've seen of reification in logic/KR has been to allow
>predicates to be used as objects, for example to allow assertions to be
>made about a category instead of the members of the category

Yes. But in RDF, we don't have all the nifty machinery this would require,
like lambda expressions. What's reified/quoted is just that, and I don't
think doing substitutions and the like within quoted stuff is possible in
any of the higher level languages currently defined on top of RDF. (KIF
has it, as LISP apps usually do, but it isn't RDF.)

>(RDF reification seems to want to make statements about individual
>statements, such as we might need for provenance).

Yes. Probably the only reason for the limited scope is the lack of higher
level semantics which deal consistently with higher order logic.

In the context of this thread RDF reification has a bit of a problem,
though. Suppose we have a multiway relation drawn from some suitable E-R
or RDBMS schema. How does one model such a thing? Breaking it into
multiple binary relations between the participant classes isn't always
possible, so the relation will have to be modelled explicitly. Tuples
become instances of a given rdfs:Class, with properties pointing out to
each of the participants. If we look at this more carefully, we'll see
that the construct is actually a reification of the relation, but
different from the RDF one. The concept of multiway relations isn't
understood by RDF, so the semantics will have to live elsewhere in the
cake. The trouble is, we now have more than one way to reify relations,
and mixing them will land us in a world of pain. RDF also will not
understand the construct, so describing such a relation won't
automagically assert it.

Originally I thought this lack of n-ary relations as a basic RDFS feature
was the very point of the discussion. Now I'm beginning to think MDaconta
advocates separate attributes and predicates while my viewpoint calls for
as little separation between the two as possible. In this sense, I don't
see anything wrong with subclassing rdf:Property (I already do that
myself, to get relations without rdfs:Literals), but going as far as
completely separating the two types at the level of RDFS will, I think,
only make things worse. I mean, at the very least it would call for a
reevaluation of the model theory spec.

>To do this reification of a property, my understanding is we need rules
>of inference, or a 'holds' relation which can be inferred for a given
>relation. As far as I know RDF/S isn't capable of describing that.
>Looking at your relations ontology (1) I /think/ log:implies is being
>used to get around this. Wrong?

Right you are. But I don't think RDFS *should* be capable of describing
semantics like this. That's what languages like KIF and that provided by
the log: primitives are for. An ontology like this can well be used as a
standalone implement in categorizing binary relations, without the
attached logic part.

>(1) <http://www.helsinki.fi/~ssyreeni/shared/meta/relations>

That's actually a bit different from what we've been talking about,
lately. It's about binary relations only, with semantics added. I've been
using it to annotate some of RDFS and DAML. n-ary relations will be in
http://www.helsinki.fi/~ssyreeni/shared/meta/associations after I sort out
the N3.
-- 
Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Monday, 22 July 2002 06:06:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:54 GMT