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.

To which I say:

      _:x rdf:type seat:SittingInTheMiddle .
      _:x seat:middle people:em .
      _:x seat:side people:danc .
      _:x seat:side people:sandro .

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.

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.

Here's what I want from RDF: I want to build open, distributed
software.  We can do this by having modules communicate through
shared databases.  I see an RDF Graph being a pretty good database.
The operations are basically insert-triple, delete-triple, 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).  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.  (There's some extra detail to
allow things like backward chaining, but it's not very complicated
either.)  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.   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.  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.   

> >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.  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. ]

> 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.

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.

> 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'".  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.

> >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?  Well,
maybe somewhere in the closed/open worldness, but vocabularies can be
built to be insensitive to that.  So if we make RDFN reasonably, at
worst there's a contradiction.  Nothing breaks.  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.

> >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.

[ 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.  And they are also true.  And that's fine, because
the ones which are "syntactic" 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.

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.  In practice, I think a mixture of DAML-type
formal ontology and for-humans text is how we'll define most
vocabulary terms.  Of course we're not really defining them, just kind
of constraining their possible meanings, etc, etc.   But lets get the
above straighted out before worrying about this. ]

(There's a bit more detail on how I propose to do these databases at
http://www.w3.org/2002/01/rdf-databases, but I imagine the level of
detail in this message is about right.)

    -- sandro

Received on Thursday, 10 January 2002 20:14:48 UTC