- From: Sampo Syreeni <decoy@iki.fi>
- Date: Wed, 17 Dec 2003 02:07:55 +0200 (EET)
- To: Xie Guotong <guotongxie@hotmail.com>
- Cc: www-rdf-interest@w3.org
On 2003-12-16, Xie Guotong uttered: >rdf:Property is an instance of rdfs:Class. From RDFS specification, we >know that "The rdfs:domain of rdfs:subClassOf is rdfs:Class. The >rdfs:range of rdfs:subClassOf is rdfs:Class." Then why we can not use >rdfs:subClassOf in definition of a Property. First, because that confuses classes with their instances. We know that rdf:Property is an instance of rdfs:Class. If you now state that :love is an instance of rdf:Property, it does *not* follow that :love is an instance of rdfs:Class. rdfs:subClassOf and rdfs:subPropertyOf do work this way -- they are transitive -- but rdf:type is different. This means that you cannot use :love as the object of rdfs:range or rdfs:domain. (rdf:Property is permissible, of course, since it *is* an rdfs:Class.) Second, you actually *can* use rdfs:subClassOf to define classes of properties (as I've done e.g. in http://www.iki.fi/~decoy/shared/meta/relations), but each of those classes is still just a class of properties, not *a* property. You cannot in good conscience use such classes as predicates in statements, for example. You can also annotate the classes with your own properties all you want, but that won't buy you *statements* with annotations (which is what you really want to do). Statements are a different thing, and they cannot be annotated in RDF. > <owl:ObjectProperty rdf:ID="hasRelationship"> > <rdfs:domain rdf:resource="#Love"/> > <rdfs:range rdf:resource="#LoveType"/> > </owl:ObjectProperty> This does not work because #love is not an rdfs:Class, but an rdf:Property. If you want something like this, you'll have to construct (by enumeration) an rdfs:Class which has just one member, #love, and use that with rdfs:domain. However... > <People rdf:ID="Tom"> > <Love rdf:resource="#Jerry"> > <hasRelationship rdf:resource="#Enemy"/> > </Love> > </People> This is doubly confusing. I think I know what you want, but it's simply undoable in RDF. It was already noted that in OWL Full (and RDFS), it's possible for a property to be a class as well. After that you can refer to it in rdfs:domain and rdfs:range. But this doesn't really help you get what you want. For example, if you have rdfs:Class is rdf:type of :love, :Person , :LoveType :. :Person is rdf:type of :Tom, :Jerry . :love is rdf:type of :Me . :LoveType is rdf:type of :Enemy . rdf:Property is rdf:type of :love, :hasRelationship . :love rdfs:range :Person ; rdfs:domain :Person . :hasRelationship rdfs:range :LoveType ; rdfs:domain :love . RDF's triple model still won't allow you to assert anything like :Tom :love(which-by-the-way-also :hasRelationship :Enemy .) :Jerry . What you *can* say is :Tom :love :Jerry :Me :hasRelationship :Enemy . but then the {:hasRelationship :Enemy} part attaches to :Me (which is an instance of :love), *not* to the first statement with :love as the predicate. In other words, we now have :Tom related to :Jerry via :love, :Me is a :love , and :Me has a relationship :Enemy -- :love works as a relation between people but there's also this thing called :Me which isn't a relation, but is an instance of something which is an instance of a relation, with a relation to :Enemy. It makes little sense, ontologically speaking. This fact is a basic feature of RDF and you cannot circumvent it without changing RDF's data model. Only binary, named relations can be expressed in pure RDF. Higher arity can only be modelled as a bunch of binary relations. UML, TopicMaps and relational databases are all capable of higher arity (a UML association is a ternary relation between two classes and an association class; an RDB table with n>=2 columns represents an n-ary relation; TopicMaps allow associations between a variable number of topics, a single association type and a single role for each of the participants in an association -- it's twice as complicated), so if you want to map their data models into RDF, all higher arity relations will have to be broken down somehow. As Guus noted, the standard way of doing this is to define an intermediate object, with the participants in your original relation hanging off it. In this case it would look something like :Tom :love [:loved :Jerry ; :hasRelationship :Enemy] . or if we want to be really pedantic and make the representation as regular and akin to a relational database row as possible, we get _:a a :LoveRelation ; :lover :Tom ; :loved :Jerry ; :hasRelationship :Enemy . If we take the TopicMap view and treat this as a free-form association, and the relations are symmetric as well (who made you think love is a symmetric relation, btw? ;) with respect to some subset of the participants, we can do even better: _:b a :LoveRelation ; :lover :Tom ; :lover :Jerry ; :hasRelationship :Enemy . <stream-of-consciousness> A further, different way to express the same thing is to use reification: :Tom :love :Jerry . _:c a rdf:Statement ; rdf:subject :Tom ; rdf:predicate :love ; rdf:object :Jerry ; :hasRelationship :Enemy . The last form prompts two amusing observations. First, when we model higher arity relations using our own terms, we're defining what are essentially reifications of the relations when viewed from the perspective of pure RDF. If you look at the first two of the above three forms, it's easy to see that a pure RDF reasoner won't understand that Tom loves Jerry, unless it has some extra data at its disposal. In the third, the reasoner won't understand what enemies have to do with it. (We could also assert :Tom :hasRelationship :Enemy and make its reification :love :Jerry, or even switch :Tom and :Jerry in the last. It's all a matter of notation, but it will change what is asserted in pure RDF and what is not.) It's much like saying {:Tom :love :Jerry .} a log:Truth . in CWM's flavor of N3 -- you have to understand the semantics before you can figure it out, but after you do, it'll simply assert something. I think this point constitutes a good reason to settle on a single, shared vocabulary for the representations of higher arity relations. Even if current RDF tools/languages do not get the idea of higher arity relations natively, later tools might. I mean, the representation is common enough. It's not even wholly inconceivable that someone might want to use relational database languages to query tables represented in RDF, and there is certainly a wealth of database and data warehouse related software which was built for n-ary relations from the start. If there was a commonly accepted way of representing n-ary relations and/or variable arity associations, I think that would help in adapting existing tools and data formats to RDF. Furthermore, since all the inferences one can make from such associations can be duplicated at the RDF level with a little bit of predicate logic, this would also make it a lot easier for RDF reasoners to accommodate higher arity relations -- you'd just need a single set of axioms to deal with the rudiments of relations/associations, instead of one for each variation on the theme. Second, if we look at RDF reification, it shows pretty clearly what RDF is: it's a language describing a ternary relation between resources. Higher arity simply forces us to layer semantics on top of that, but from the viewpoint of RDF reified triples and represented higher arity relations seem the same. Just as representations of higher arity relations are dark as far as pure RDF goes, so are reified triples proper; subjects/predicates/objects aren't that different from relation/association members, either. It's just that in a framework which understands the layering, higher arity is on par with the binary, named relations RDF can represent natively. In a semantically rich environment both can become asserted, even if pure RDF doesn't recognize them as such. For example, :Tom :love :Jerry . _:c a rdf:Statement ; rdf:subject :Tom ; rdf:predicate :love ; rdf:object :Jerry ; :hasRelationship :Enemy . is equivalent to _:c a rdf:Statement ; rdf:subject :Tom ; rdf:predicate :love ; rdf:object :Jerry ; :hasRelationship :Enemy ; a log:Truth . and closely parallels the hypothetical _:c a rdf-ext:Relation ; # rdf-ext:Relation rdfs:subClassOf rdf:Seq . rdf:_1 :Tom ; rdf:_2 :love ; rdf:_3 :Jerry ; rdf:_4 :Enemy ; a log:Truth . The symmetry sorta makes me want to argue that all dark triples should be represented via the standard reification mechanism, and that the latter should be made a subconstruct of a standard way of representing higher arity relations. Reification ain't concise, of course, but it works. For example, contexts (CWM-like or otherwise) should probably be exchanged in reified form. For example, {:Tom :love :Jerry .} a log:Truth . would become _:d a cwm:Context ; cwm:asserts _:e ; a log:Truth . _:e a rdf:Statement ; rdf:subject :Tom ; rdf:predicate :love ; rdf:object :Jerry . while brevity would probably forbid multiple reifications: {{:Tom :love :Jerry .} a log:Truth .} a log:Truth . would get across as _:f a cwm:Context ; cwm:asserts _:g ; a log:Truth . _:g a cwm:Context ; cwm:asserts _:h ; a log:Truth . _:h a rdf:Statement ; rdf:subject :Tom ; rdf:predicate :love ; rdf:object :Jerry . rdf:Statement would then become a subclass of rdf-ext:Relation (which would be a subclass of rdf-ext:Association), and would have restrictions on its properties which more general relations wouldn't. If this analogy is carried just a little bit further, we might also require asserted higher arity relations/associations to be accompanied by contexts which explicitly assert them -- after this the different orders of reification of all rdf-ext:Association's would look the same. And if we reinterpreted normal RDF assertions as a common shorthand for a reified triple asserted to be a log:Truth, even the asserted forms would be precisely analogous... </stream-of-consciousness> -- 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 Tuesday, 16 December 2003 19:07:59 UTC