- From: pat hayes <phayes@ai.uwf.edu>
- Date: Thu, 17 May 2001 21:08:55 -0500
- To: Sandro Hawke <sandro@w3.org>
- Cc: www-rdf-logic@w3.org
> > >[ Drew McDermott:] For me, "get rid of triples" has become >shorthand for "get rid of the > > >assumption that asserting a structure of triples asserts every triple > > >in the structure." > > > > [Pat Hayes:] I thought that was what you meant. I agree. In fact, >I would take it > > further and say that we should get rid of the assumption that every > > triple is assertible. Some triples should be seen as fragments of > > larger structures which are not even well-formed by themselves. > > > > >I have no objection to binary predicates; I could > > >even live with all predicates being binary if it would allow me to > > >speak for lots of ontologists. :) > > > > The restriction to binary (plus unary, ie at-most-binary) predicates > > is mildly inconvenient but quite live-with-able, I agree. That's two > > ontologists on the list. > >I want all communication to be equivalent to passing one or more >triples. I want to think of the knowledge held by each entity as a >set of triples (which might be modified and/or queried). > >For example, I might want tell some entity that if it has the triple ><A,B,C> in its store, it should remove it. I want to say something >like: > > there exists some triple T with a first > element A, a second element B, and a > third element C. If you currently believe > T to be true, forget that fact. I have NOOO problem with you doing that, let me emphasise. But what I want to be able to do is to represent something other than a single triple, and say it is true/should be forgotten/was derived from these other things/was sent to me by someone whose URL ends in ".edu"/whatever. In other words, the problem is not being able to say all these good things about assertions: it is that triples (alone) are not adequate to be the assertions. They are too SMALL. They don't let me say what I want to be able to say: they don't let me say (NOT ...) or (... OR ....) or (EVERY .... IS ....). These kinds of assertions need more than single triples, you see, because they have more than three parts. A simple point, surely? (And please don't tell me that you can do this with "reification". I know, I know: read on.) Now, you can always take one of these more-than-triple things and hack up a structure of triples to encode it, sure. So in a sense you can think of the knowledge as a set of triples, or at least encoded in a set of triples. But then that encoding is NOT A LOGICAL CONJUNCTION. It is a data-structure which is being used to represent a piece of syntax. Again, I have no problem with that either. What I do have a problem with is getting these confused with one another: with a notation (like RDF) that says that it is just conjunctions of triple-style atomic assertions, but also wants to be a datastructure language for encoding more complex assertions. You can't have it both ways: if RDF is really your assertional *syntax*, you have a (no doubt useful, but) severely limited language for expressing things. For example, in this language, there is no such thing as contradiction, since there is no negation. That is one way to go, OK. Another way to go is to say that RDF triples can encode more complex expressions (they can be used as simple assertions as well, as long as you can somehow tell those from the structural ones), and these more complex thingies are what are the assertional syntax. Now, I would call this having another language and implementing it in RDF, but if you like to call it something else that is fine; fashions change in terminology like anything else. You can even call it "reification", I guess, but if you do, I wish you would, just on the grounds of good writing style, use scare quotes or something to indicate that what you call "reification" isn't what the rest of the world (including the RDF spec) means by the word "reification". Real reification cannot be used to encode complex syntax. (It can be used to describe it, but thats not the same thing: see use/mention discussions elsewhere on this thread.) But whatever you call it, the point is that the *logical* syntax in this case is NOT the triples, but these more complicated structures that are being implemented as sets of triples. So we need to somehow specify the rules for what counts as being well-structured (not every set of triples will be) and we will probably need a few datastructuring primitives (like end-of-chain markers, cf. Lisp NIL.) In other words, we will have to do a little work. Just a tad, but we will need to do it. Sorry if that's not anarchic enough. (There isnt anything odd or exotic about all this, let me emphasize: its is just ordinary bread-and-butter datastructure design. We really do teach it to our undergraduates.) Pat Hayes --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Thursday, 17 May 2001 22:09:00 UTC