Re: Grist for layering discussion

>  > I'm following Aaron's lead and Ccing it to  <www-archive@w3.org>, OK?
>Yep, thanks.
>
>Meanwhile, on to the message....  Wow.  Serious disconnect.  "Either
>this man is dead, or my watch has stopped!"
>
>But I can't quite see where.  
>
>Danbri says he thinks he knows what you're saying:
>
>       Think of how you might say "em is sat between danc and sandro"
>       using triples. The whole document is saying more than each
>       atomic triple; and RDF itself doesn't acknowledge any
>       granularity of meaningfulness above single triples.

That's an interesting point but it has nothing to do with what I was 
talking about.

>To which I say:
>
>       _:x rdf:type seat:SittingInTheMiddle .
>       _:x seat:middle people:em .
>       _:x seat:side people:danc .
>       _:x seat:side people:sandro .

Right, that is one technique for mapping a 3-place relation into 
binary relations. Its often linked to 'case' structure in NL parsing, 
where one thinks of, say, "He did it in the kitchen at midnight with 
a knife" (Davidson's example) not as Did-it(he, kitchen, 
midnight,knife) but rather as
(exists (?x) (and (event ?x)(agent ?x He)(place ?x kitchen)(time ?x 
midnight)(tool ?x knife)))
which has some clear advantages. However, it needs some discipline to 
stick to a 'standard' set of relation (property) names if its going 
to be globally coherent.

>Danbri says:
>
>       Problem is: the 'seat:middle' bit isn't standalone contentful,
>       but is meaningful as part of a larger packet of
>       information. It's not untrue, just uninformative, to assert it
>       alone.

No, I would disagree. If you don't know the conventions for sitting 
in the middle it might not be much use, but its still meaningful and 
can stand on its own.

>I say:
>
>       True.  That one triple is like a pixel on my screen being dark.
>       It's one of many pixels that draws the hour-hand on my clock;
>       together they tell me the time.   That's a good thing.  Pixels
>       are very useful.   A pixel only tells me something when I have
>       enough context to care whether it is light or dark.  That's
>       probably true of triples.  Sometimes the context comes from the
>       surrounding pixels/triples (other triples sharing terms),
>       sometimes the context comes from outside the system, like a Post-It
>       note on my screen pointing to a pixel, or an arrangement that
>       people:em means something.

I would suggest avoiding this talk of 'context' and analogies with 
visual media like pixels. It only gets into swamps of muddle and 
confusion, and there's no need for it. All this thinking has already 
been done, and conventional theories of meaning (eg model theory) 
handle assertional languages quite adequately. (The pixels analogy is 
particularly unfortunate since it involves vision, which introduces a 
whole other swamp of misleading analogies. God forbid we should 
re-explore all the confusions surrounding 'mental images'.

>Here's what I want from RDF: I want to build open, distributed
>software.

RDF is not a software language. Use Java.

>We can do this by having modules communicate through
>shared databases.  I see an RDF Graph being a pretty good database.

It is a pretty good simple kind of database. VERY simple, but 
sometimes that is just what you want. As a basis for serious work, 
its too simple, in my view. I don't think the SW will start to 
actually work seriously until we can be in a situation where one DB 
can contradict another, or where two DB's can have consequences that 
don't follow from either one alone.

>The operations are basically insert-triple, delete-triple,

Deleting a triple is not a valid operation in RDF. If you try to 
delete one of my triples, that would be an act of sabotage.

>and the
>kind of queries we've talked about in the joint-committee.  Very
>simple, very ordinary, except maybe a little odd around anonymous
>nodes (and too simple for most folks to bother with, in practice).

Right. So simple that nothing very much can be done with it, in fact.

>  An
>RDF database can be stored naturally as an N-Triples file. 
>
>Reasoners in this world are just like other modules -- they query the
>database and they insert/delete stuff.

I would like to know what other modules you have in mind that would 
do anything to a database (apart from things like editors which are 
used to create the DB in the first place). All valid operations on 
data are some form of inference or reasoning.

>  (There's some extra detail to
>allow things like backward chaining, but it's not very complicated
>either.

It has some little wrinkles that can be a bit tricky; but I agree the 
technology is broadly well-understood.

>)  Actually, I think I want to add a flag to a database which
>says whether it's inconsistent, but that could also be done with a
>well-known triple.

Whoa!  Wrong. It couldn't be done while conforming to the RDF spec as 
published. Those triples are not completely at your disposal to mean 
anything you like. The spec puts severe restrictions on what they can 
mean. This isn't like implementing arbitrary software. If you want to 
do that, use Java.

>  In either case, checking for that is kind of like
>checking for error-codes, either manditory or just a darn good idea.
>
>The difference with reasoners is just that they are totally focussed
>on the data -- they have no other I/O.  (Kind of like a person sitting
>still with their eyes closed, doing reasoning.  :-)  
>
>If multiple reasoners are attached to the same database and they
>disagree about whether some triples should be in it, well, there's
>some configuration info that says what to do.  In the most
>conservative case, you just raise the "inconsistent" flag at that
>point.
>
>As I understand it, from this perspective a Model Theory is just a way
>to help specify the behavior of a reasoner.

Then you don't understand it. Sorry, but there's a limit to the 
extent to which I have time to re-educate y'all. Read some more about 
it before delivering your opinions, I would suggest. The MT specifies 
the *meaning* of the stuff in the DB. It does not specify behavior; 
in fact, that is one of its great utilities, in that the meaning is 
NOT dependent on any particular behavior - its not procedural.

>  I understand that people
>have written (and been!) lots of kinds of reasoners over the years
>which they could not explain clearly enough, and that model theory has
>helped.  That's fine.  Maybe one should be careful to only attach
>reasoners which have compatible model theories, if one wants to avoid
>the kind of conflicts mentioned in the previous paragraph.  And other
>people will just take their chances.

This does not make sense. An MT is not attached to a reasoner. It is 
rather attached to the notation of the DB itself. The MT specifies 
the conditions under which an interpretation makes a DB true, and 
hence the conditions under which a transformation on DB expressions 
preserves truth. (Without that, its not even worth calling it 'data'; 
its just arbitrary strings of characters or bits.) So, you have to 
say what notation the DB is supposed to be in before it even makes 
sense to talk about its MT (or issues like consistency). The problem 
Im talking about is that when we encode RDFN (or DAML+OIL) into RDF 
triples, we have one set of triples that can be 'read' in two 
different ways: as an RDF DB or as an RDFN DB, and these two ways 
disagree. That is *not* a DB inconsistency, just to emphasize the 
point again; it is an anomaly in the specifications.

>
>>  >not all that different from
>>  >    a rdfn:notAllString "c1 c2 ... cn" .
>>
>>  Right, an RDFN reasoner can be happy. The problem is that an RDF
>>  reasoner can also look at these triples, and would be entitled to
>  > draw conclusions from them, and those conclusions could mislead the
>>  RDFN reasoner. For example, it follows in RDF from the above that
>>  _:x b1 c1 .
>>  _:x b2 c2 .
>>  ....
>>  _:x bn cn .
>>  ie that something exists which has the bi relation to ci.  That is a
>  > valid RDF-consequence from those triples; but it is *not* a valid
>>  RDFN consequence from
>>
>>  a rdfn:notAll b1 c1 ...bn cn;
>
>No, it's not a consequence of that -- it's just a way of communicating
>it to an RDFN reasoner.

?? Why would I want to use an RDF encoding to communicate well-formed 
RDFN to an RDFN reasoner? The RDFN reasoner will need to parse the 
RDFN somehow, and its *easier* to do that from the native form of the 
RDFN than it is by reconstructing it from an encoding into RDF 
triples. (If they were all written as XML schemas then it would be 
even easier.)  Passing RDFN through RDF  just gets in the damn way 
and makes life harder for everyone.

But in any case, the central point is that once it has been 
transcribed into RDF, there is no way *in RDF* to tell that RDF-valid 
operations should not be performed on it. In fact, the RDF spec 
asserts that all such conclusions *are* valid consequences.

>  The RDFN reasoner will reconstruct the long
>tuple and use it; it will also see the { _:x b2 c2 } in the database,
>but in the natural course of using RDF there is always such junk you
>must ignore in the database.  [ see below. ]

If you find that 'natural' then you are not using RDF according the 
the RDF spec. Now, maybe that is fine for you: you are free to do 
what you like. But I am involved with getting the RDF spec right, and 
if one has to violate the spec in order to use RDF, then Im not happy 
about that.

>  > No, it won't, if the software has to respect the specs, and those
>>  specs include model-theoretic semantics. Once you publish some
>>  triples, then any RDF engine anywhere on the planet can stick them
>>  together with some other RDF triples that you have never even seen,
>>  and is entitled to draw any valid conclusions from them.
>
>Except RDF doesn't have any interesting conclusions.   Just the
>trivial conjunction elimination and existential introduction.  Barely
>even worth mentioning.

I tend to agree, as a general point; but as a matter of fact, RDF has 
enough conclusions to break the RDFN mapping I put forward 
(admittedly as a straw man to make a point, but its that point we are 
arguing about, right?)

>
>RDFS has a lot more -- but that's a reasoner attached to the database.
>
>>  Its no good
>>  your saying that you only meant them to be used some particular way;
>>  you can't say that in RDF, and once the triples are loose on the web,
>>  you have no control over them.  Maybe your RDFN engine will work
>>  fine, but some other engine might do all kinds of crazy stuff while
>>  still satisfying the RDF specs, and then whose fault will that be?.
>
>Their fault.  The specification of the objects used in each triple
>tells you what you're allowed to do with them.  Maybe that's where the
>MT is needed, to make those instructions more clear.

They would be conforming to the RDF MT. That is my point. And the 
answer is NOT 'their fault'. If we (ie the W3C) publishes a standard 
document, and software that conforms to that document breaks while 
conforming, then the problem lies with the people who published the 
broken spec., not the users who conformed to it. We need to get our 
act together, not just shout at the rest of the planet to be better 
hackers.

>
>>  The point is that assertional languages with defined semantics are
>>  *not* Perl-style programming languages. Once you publish a semantics,
>>  you can't over-ride that semantics to serve a higher-level
>>  implementation trick. Each RDF triple is an assertion which stands on
>>  its own, and if you assert it, then you take the rap for any valid
>>  conclusions that can be drawn from it.
>
>While I'm not sure it matters, I really don't see any harm in telling
>the whole universe for all time that
>        _:x seat:middle people:em .
>or "there is something, which I call '_:x' in this document, which has
>a 'seat:middle' property with the value being denoted by
>'people:em'".

I agree, no problem with that. That doesn't violate any spec., though.

>Nobody can make any sense of it without knowing
>something about at least one of those three triples.   And I think
>we're suppose to prejudice it so you have to understand the predicate
>'seat:middle' first (and only care about the others if it says you
>can).
>
>>  >  Only a
>>  >reasoner who knows the FOL vocabulary can do anything with the
>>  >triples.
>>
>>  An RDF reasoner can draw any valid RDF conclusion from them. That is
>>  exactly the point. Now, are you sure that all such RDF-valid
>>  conclusions are still FOL-valid (using the same syntactic
>>  >embedding)?
>
>Yeah, they can conclude that any subgraph with any node labels removed
>is also true.  If that's going to affect my FOL reasoner, I've done
>something very wrong in my FOL vocabulary.

Even if one of those labels is 'not' ? You can't have it both ways: 
either you have encoded all of FOL or not. I havn't checked the 
details, but if you used an RDF arc label to encode FOL 'not' then 
you havn't done the embedding right, because 'not' is not a relation..

>
>>  >1.  What if your transcribed NotAll expression says that one of the
>>  >triples used to transcribe it is false?
>>
>>  As it does in the example above.
>>
>>  >  Actually that's not a
>>  >problem; it's just a contradiction.
>>
>>  No, it is a problem. It shows that the RDFN meaning of a statement
>>  and the RDF meaning of the transcription of that statement can be in
>>  direct contradiction. That is not a contradiction, but an
>>  incompatibility between the languages.
>
>If RDFN really could be incompattible with RDF itself, that would be a
>problem.  In my database view, how could that be possible?

Easy. It says something that can't be said in RDF. RDF, as you point 
out, is a very weak logic. Its easy to invent logics (like RDFN) that 
can say things that can't be said in RDF.

>   Well,
>maybe somewhere in the closed/open worldness,

Nothing to do with that.

>  but vocabularies can be
>built to be insensitive to that.  So if we make RDFN reasonably, at
>worst there's a contradiction.  Nothing breaks.

No, it does break. (I am not going to explain this again, I can't do 
it more clearly than I already have. )

>  If the contradictory
>data is deleted (and it would be, automatically, in a
>transaction-based system, as long as the logic can tell us about its
>problems) everything is fine.  If you add the final triples to
>complete an "A and not A" sentence in the FOL vocabulary an attached
>reason is using, your addition is rejected or makes the database
>inconsistent, and if it can, the reasoner will tell you.  Sounds like
>a good situation to me.

None of the above either makes sense or is germane to the point I was 
making. You have to say, inconsistent *in which language* ? There is 
no such thing as simple inconsistency; the term is only meaningful 
relative to a particular model theory and a particular language.

>
>>  >The NotAll reasoner will view the
>>  >graph as not satisfiable (invalid), just as it would if some more
>>  >normal triple had been contradicted.
>>
>>  But there is no contradiction here either in RDFN or in RDF. They
>>  just disagree.
>
>Yes -- I'm saying when two reasoners disagree, it's a problem caught
>at a higher level, which can be configured to call that another kind
>of contradiction.

Wrong. There is no such 'higher level' . One might expect that two 
reasoners in different languages might disagree, even that isn't 
really a problem (though it may be a practical inconvenience.) The 
problem is that by saying that an RDFN DB *is* an RDF DB, we have 
made a reasonable disagreement into an incompatibility between our 
published specifications. Just as by saying that a DAML+OIL DB *is* 
an RDF DB, we have created a problem where no problem existed before.

>[ lots of interesting stuff skipped for now. ]
>
>>  >Is the hack just in the MT, or does it affect, say, N-Triples?
>>
>>  N-triples doesn't have any way to snag my hook right now. It wouldn't
>>  be hard to add it, eg suppose we allowed some triples to be
>>  terminated by a semicolon rather than a dot, and then the rule would
>>  be that only the dotted triples were understood to be asserted in
>>  RDF, and the others were being used for some other purpose (known
>>  only to some higher-level processor.) Like I said, its ugly, kind of
>>  like a plumber using stop-leak, but it would stop the leaks.
>
>To me all the triples are just there to be used by whatever processors
>want to use them.

Well then, read the published specs, and think again.

>  And they are also true.  And that's fine, because
>the ones which are "syntactic"

Whoa. Which are those, exactly? Where in any published part of the 
RDF(S) spec does it say anything about which triples are "syntactic" 
and which ones aren't?

>  spend their entire life just telling
>people about syntactic structures.  The properties of those syntactic
>structures are the truth they convey.  If someone asks "how many
>triples in the database have the object 'Pat'?" they are breaking the
>rules, because they didn't pay attention to the meaning of the
>predicate.

They cannot, and should not, pay any attention to any aspect of 
meaning that is not itself encoded in RDF.  RDF, like any other 
*formal* expressive language, has to be taken on its own merits. It 
doesn't come along with a user manual written in English which 
explains what all the URIs are supposed to mean and how to use them 
properly. There are no "rules" to break, other than those that can be 
inferred from the spec (including the model theory.)  This is a very 
important, basic, fundamental point in knowledge representation. The 
*only* meaning in any formal KR is in the KR itself. You cannot 
appeal to some other representation to tell you what it means. Get 
used to this, or you will never come down out of the clouds.

>
>More grist.   :-)
>
>[ And some random musings about stuff I don't really understand
>(unlike the above, about which I couldn't possible make a mistake :-)
>...  Am I really just saying that every RDF Predicate needs to be
>associated with some model theory?  I used to think they would all be
>defined axiomatically, but now think there can be no logic we could
>use for those axioms.

Just an aside, but: why not?

>  In practice, I think a mixture of DAML-type
>formal ontology and for-humans text is how we'll define most
>vocabulary terms.

Then you are playing a different game, and one I'm not interested in 
(and for the record, think that is either impossible or trivial, 
depending on how you spin it.). The SW is supposed to be about making 
SOFTWARE take decisions. Software doesn't read for-humans text.

Pat
-- 
---------------------------------------------------------------------
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 Friday, 11 January 2002 16:28:43 UTC