- From: Thomas B. Passin <tpassin@comcast.net>
- Date: Mon, 01 Jul 2002 01:01:01 -0400
- To: www-rdf-logic@w3.org
[Enrico Franconi] > > On June 30, Thomas B. Passin writes: > > 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. > > I don't really understand what are you saying. We do know the primary > key; the problem is that it is not made out of a single property, but > it is the whole set of properties. > I see, I couldn't be sure from your post. I don't think it changes the argument, though, to have the primary key equal the set of all columns in a table (or equvalently, all properties in the relationship), as long as which properties are allowed is unchangable. Seth was showing templates for n-ary relationships, and for templates to work with RDF there has to be some predicate that connects a template to its instance. RDF cannot (of course) express the semantics of that connection. > > 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. > > Again, what are you saying is rather obscure. The additional > constraint I want to enforce is by no mean higher order, neither it > involves higher order relationships. It is pure first order: > I realize that, I was going beyond your example following some other thoughts that this thread kicked off. > \forall x1...xn . R(x1,...,xn) <--> > \exists-unique z . RC(z) \and r1(z,x1) \and ... \and rn(z,xn) >
Received on Monday, 1 July 2002 01:00:15 UTC