RE: ACTION 2001-11-02#02: Datatyping use-cases from CC/PP

At 08:21 PM 11/14/01 -0600, Pat Hayes wrote:
>Maybe I see what is bothering you. The purely descriptive model we 
>currently have can deliver all inferable typing information to an external 
>type-checker, and if it finds any contradictions then it can report those, 
>or deliver enough information so that the checker can notice them. But 
>that alone doesn't say which one of these type-assertions is the local one 
>and the other is the global, or distant, one.  So if a type-checker wants 
>to use the *local* information to make its decision - if it wants to treat 
>THAT information as prescriptive rather merely descriptive, if I have this 
>distinction right now - then it will be stymied, because the purely 
>assertional nature of the RDFS reasoning process treats all sources of 
>information as having equal claims on the truth, as it were. It doesn't 
>enable the external type-checking engine to use a local-preferring default 
>procedure to make its decision in the face of a conflict between local and 
>global information about types, because it doesn't even have the 
>distinction available. It can report a conflict, but it only does do 
>neutrally; it doesn't take sides; whereas in this case you *want* it to 
>take sides, in order that the external process can more rationally decide 
>what to do.
>
>Is that more or less right? because if so it raises an interesting issue 
>about RDFS generally, in fact, which I think goes beyond just data-typing: 
>there may be more information 'in' an RDF graph than just the content of 
>the triples that make it up.

Well, yes.  I have for some time settled myself to the idea that core RDF 
will not, of itself, have the generality that you mention.  But I have come 
to a view that this is a matter for using provenance information, which I 
think can be encoded in RDF in a number of ways (so-called "reification" 
being one).  I further think that the semantics can be captured using the 
closure mechanisms that you introduced for RDFS.

Example (this could almost be CC/PP) (using N3):

    my:device dev:type acme:messageWidget ;
        prf:onReceiveMessage "Vibrate" .

    acme:messageWidget a dev:Description ;
        prf:onReceiveMessage "Beep" ;
        dev:screenHeight "4" ;
        dev:screenWidth  "40" .

from which we want to infer, using the closure mechanisms:

    my:device dev:type acme:messageWidget ;
        prf:onReceiveMessage "Vibrate" ;
        dev:screenHeight "4" ;
        dev:screenWidth  "40" .

Here, it is the inference mechanism that determines that the 
acme:messageWidget option for prf:onReceiveMessage does not override the 
locally specified option.  If the option had not been specified "locally" 
then the acme:mesageWidget value would be applied.  [** the 
non-monotonicity caveat noted below applies here.]

This example is very specialized to a particular application.  It depends 
crucially on special inference patterns being defined for dev:type.  Also, 
the rules of RDF mean that in the particular form given above the statement
    my:device prf:onReceiveMessage "Vibrate" .
cannot be discarded in favour of the other value.

I think the approach can be generalized.  CC/PP does this to a degree by 
defining a "default" property (effectively with its own rules of inference 
[**also non-monotonic]).  I think a more generalized approach could be 
based on something like the "lifting rules" of McCarthy/Guha's work on 
contexts.  But most importantly, I think this can be built using current 
RDF as a base.

OR, when you say (above):
>... there may be more information 'in' an RDF graph than just the content 
>of the triples that make it up.
one might say "of course there is":  not only are the semantics of RDF 
implied, but also any closure rules associated with the node/arc 
identifiers that are present in the graph.

[** However, I think that if you want to have such inferences that go 
beyond neutrality, as you suggest above, you end up needing an element of 
non-monotonicity;  i.e. some outcomes may be due to the absence of some 
statement in the graph.  This goes to a whole new debate which is not the 
point of this message.]

#g


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
       __
      /\ \
     /  \ \
    / /\ \ \
   / / /\ \ \
  / / /__\_\ \
/ / /________\
\/___________/

Received on Thursday, 15 November 2001 09:52:41 UTC