- From: Thomas B. Passin <tpassin@comcast.net>
- Date: Sun, 30 Jun 2002 22:36:43 -0400
- To: www-rdf-logic@w3.org
[Enrico Franconi] >The problem is: how to write this constraint in RDF? > > If you ask me an example on the fly, I tell you the following: > > teach(john,cs336,sem2,2001/2002) > teach(john,_z,sem2,2001/2002) > > which becomes, reified: > > teach(_x) > prof(_x,john) > course(_,cs336) > semester(_,sem2) > acad-year(_,2001/2002) > > teach(_y) > prof(_y,john) > course(_y,_z) > semester(_y,sem2) > acad-year(_y,2001/2002) > > How can you tell whether _x and _y denote distinct URIs? In this case the problem is equivalent, I think, to not knowing the primary key for a relational table. Suppose we knew the key, that is, the set of properties that make each instance unique. Then we could represent them in RDF as a bag. Of course we need a predicate that can apply the key to the specific relationship. Depending on what the key really was, we could tell if these two instances were actually one and the same. This would be the constraint Enrico was talking about. This suggests to me that the problem with this particular example is a data modeling problem and not a fundamental problem of representation. Of course, there is no way in RDF to actually define such a primary key constraint beyond asserting the bag (the semantics of a primary key, in othe words), but the same can be said for almost all predicates that can be used in RDF statements.. The real problem about n-ary relationships in RDF is that, so far as I can see, you cannot distinguish between higher-order relationships, where one argument brings the others into a relationship (c.f. Sowa discussing Pierce's "thirdness"), and an ordinary first-order relationship containing a simple collection of properties that just happen to occur together. But maybe we do not have to be too discontented with RDF for not being able to represent higher order relationships when it is far from a full first-order system anyway. Cheers, Tom P
Received on Sunday, 30 June 2002 22:35:57 UTC