Re: Associations in RDF

Hi Leo,

In a message dated 7/22/02 5:10:02 PM US Mountain Standard Time, 
lobrst@mitre.org writes:
> I also wonder about the notion of "subordination" here, Mike. Do you mean
>  implicit subordination because the "subject" is the focused thing simply
>  because it is the subject? And so the triple is kind of an assertion 
> primarily about the subject (with the verb and object somehow being 
subordinate)?

No.  A triple definitely does not imply subordination. Subject, Predicate and 
Object are pretty clear ... and all are first-class objects. I think decoy has
elegantly argued about this and I agree with him.

Here is an example from an earlier post to demonstrate relation versus 
attribute:
>>>
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 classes 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.
<<<

Bound Characteristics of an object should be subordinated, relations should
not.  In researching RDF calendaring I stumbled across an architecture
that expresses what I was looking for.  It is at:
http://ilrt.org/discovery/harmony/docs/abc/abc_draft.html

It clearly separates relations from attributes.  It defines relations as:

4.2.2.2 Relations
These are properties between two (or more) resources. They include properties 
which are complex attributes such as: abc:agent (which indicates agency with 
respect to some contribution), abc:contribution (which represents the 
contribution made by some agent to an event), and abc:role (indicating the 
role played by some agent's contribution to an event). But they also include 
relationships such as DerivedFrom, PartOf, Neighbours, Siblings and the 
temporal and spatial relationships encountered within audiovisual resources. 
Relationships can be unary, binary or n-ary and uni-directional or 
bi-directional. Initially we will restrict relationships to binary and assume 
that n-ary relationships can be expressed as multiple binary relationships. 
Ideally one could define a set of elements and express, using the data model, 
an n-to-n relationship between all of the elements within the set e.g., the 
n-to-n 'neighbours' relationship.

>  In KR mostly we consider relation and attribute to be equivalent, i.e., 
just 
> a relation (and property as a relation). I know there are some stumbling 
over
>  this terminology, mainly because some of it comes from math/logic, some 
from 
> KR (both frame- and description logic systems have different terminology), 
some
>  from other communities. I think you are considering "attributes" as somehow
>  more tightly connected to an object than the relations it enters into with
>  other objects, but that might really be an illusion. There may be more of a
>  tendency to consider relations as somehow more evanescent or transitory
>  (predicates or predications) than attributes (attributions), but there are
>  problems with that.

I disagree with the notion that attributes and relations are equivalent.
In fact, I would say that not distinguishing between the two is the reason
why applications like RSS and Dublin Core don't really have any good 
reason to be modeled in RDF (because they just do some simple class/attribute
modeling).  My contention is that XML Schema can be used to model 
class/attributes 
using a fixed context.  Most business don't care about fixing the context.  

So, relations like "foaf:knows" are a key differentiator for RDF.  One that I 
would
like to exploit cleanly and efficiently.  That would be simpler if something 
like 
rdfs:Relation existed but it surely can be layered on top.  The only other 
possible reason for
separating the two is that I feel you highlight your strengths -- you don't 
hide them.
In my opinion, unifying relations and attributes stresses the wrong aspect of 
RDF.

I think I may have flogged this horse enough...

Talk to you soon,

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

Received on Monday, 22 July 2002 23:36:17 UTC