- From: <MDaconta@aol.com>
- Date: Thu, 18 Jul 2002 18:34:59 EDT
- To: decoy@iki.fi
- CC: www-rdf-interest@w3.org
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