# Re: Associations in RDF

From: Sampo Syreeni <decoy@iki.fi>
Date: Thu, 18 Jul 2002 21:25:37 +0300 (EEST)
To: <MDaconta@aol.com>
cc: <www-rdf-interest@w3.org>
Message-ID: <Pine.SOL.4.30.0207182108330.25461-100000@kruuna.Helsinki.FI>

On 2002-07-17, MDaconta@aol.com uttered to www-rdf-interest@w3.org:

>To me, predicates seem to have two types: relation (or association) and
>attribute.

How are attributes different from relations except perhaps for their
typical value range? I mean, mathematically speaking an attribute is just
a member of the image of an object in a certain relation, that is, a
member of X \times Y where X is the set of objects and Y the set of values
this particular attribute may have. I would view the uniform treatment of
attributes and relations as a big, big plus -- you only have to implement
the tools once, and everything's beautiful from there.

>For example, what about independent or temporary associations that
>should not be tightly bound to a subject?

There's no essential difference between relations and attributes, in this
sense. Lots of intermittent ones in both, I would argue.

>Additionally, a relation that has an aspect of degree is poorly modeled
>via a property.

True enough. But you can still model any such construct by willing a
separate association type into existence. You would model each "degreed"
association as a member of such a type, with properties (TopicMap people
would say facets, I think) hanging off the instance. That's a lot more
powerful in other ways, too, being that it can model n-ary relations, and
ones of variable arity. Again, see TopicMaps for examples.

>If we modeled all of these as properties, the property list of an object
>would grow to be unmanageable.

Not really. Declare all of them subproperties of a single friendship one
and do your typing with the superproperty. Ideally the fact that many
different grades of friendship are present will ideally be sealed out of
sight within some relevant API.

>Instead we need to put characteristics into the association itself.
>Thus, we model an Association as a class and we can have a simple
>property that points to a particular association subclass hierarchy.

Precisely. That's what I was trying to say, above. But that certainly
doesn't stop one from implementing attributes in the same manner. Actually
the capability can be quite useful.

>Thus as a separate first-class object, associations can be rapidly
>queried against and not be confused with simple properties.

Don't forget that everything in RDF is a triple. The XML serialization is
just that, a serialization. In the model, everything's just as efficient.
Sticking an extra class in the middle to model a more complicated
association *will* slow things down, but if you're that worried about it,
nobody stops you from embedding some extra facilities for such relations
in your triplestore. I believe that's a proven stunt with Schema based XML
and RDF stores -- I've coded stuff on top of two, now.

>I just think this is so basic that it should be in the base RDFS spec.
>
>What do you think?

Pardon my French, but hell no. RDF is one of the few W3C specs which can