- 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>
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 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. -- 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 Thursday, 18 July 2002 14:25:42 UTC