Re: Associations in RDF

In a message dated 7/18/02 11:26:02 AM US Mountain Standard Time, 
decoy@iki.fi writes:
> >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.

Attributes and relations are different in terms of subordination, types of 
values (not
range)  and semantics.  
Let's look at a common database example:
If I have the following tables (could be classes): employee, department

The employee table would have attributes like:
name, SSN, dateHired, etc.
Department could have attributes like: name, dnumber, managerSSN, location, 
etc.

A relation between these two classe would be something like 
"WorksFor" 

In the database world, WorksFor would be modeled in a separate table with
an EmployeeSSN and Department number.  In other words, the relation connects
these two entities in some way.  The relation itself is not part-of or 
subordinate
to either entity.  Semantically speaking, the concept of "working for" should 
not be
a bound characteristic of the Employee class as it is a temporary condition.  
So,
while I know you can model it with a "worksFor" attribute that is a reference 
to 
a Department object ... I would argue that makes your class brittle and 
logically
incorrect.  So, I am saying that I don't think we should model relations as 
members of a Class.  In object-oriented programming terms, I am saying that a 
simple property as a reference type to another object is not good enough if 
you have a situation where the relations are more important than the entities.

>  >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.

I hope I explained the difference above.
  
>  >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.

This is what I am asking for.  But I am saying that it is so basic that 
the "separate association type" should be an integral part of RDFS so
that all tools will understand it.
  
>  >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.

Again, this is the idea but I would prefer not to have
dc:relation, my:relation, your:relation ... etc. there should be a 
universal rdfs:relation that can be subclassed.  
  
>  >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.

Yes, but RDFS layers the concept of Classes on top of the S, P, O of the 
triple.
Thus I would expect somebody to search subjects for that are instance of 
"Employee".
Thus, if indexed properly, a search for an Employee instance is not a search
of the entire space (though I admit I don't know if RDF stores index this way 
or
even at all).  Given that some efficiency is gained by specifying membership
in one class over another (in terms of reducing the search space), the same 
efficiency
would apply to separating predicates into Properties versus Relations.
  
>  >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
>  still be called "neat" or "elegant". Overloading this sort of thing,
>  especially when it doesn't make the language any stronger, is IMHO a Bad
>  Idea.

This is a separate issue -- but you really think the spec is elegant?  I 
think this
is a good topic for a separate thread as I would disagree.  Instead, I would 
argue
that it mixes metaphors (linguistics and OOP); is at times ambiguous where 
the 
rubber meets the road (due to multiple serializations) and is unclear about
what it does best (resource description versus knowledge representation).  As 
proof of the above, I would point to its lack of mainstream adoption.   

I would like to see RDF succeed because I believe it is moving us in the 
right direction ... but I fear its current implementation is lacking.  I look 
at this
from the perspective of a CIO who has to ask the CEO to invest hard-earned
dollars on their strategic technology direction.  Do you bet the business on 
RDF 
in its current form?

Best wishes,

 - Mike
----------------------------------------------------
Michael C. Daconta
Director, Web & Technology Services
www.mcbrad.com

Received on Thursday, 18 July 2002 18:36:03 UTC