- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Thu, 15 Nov 2001 14:06:37 +0000
- To: Pat Hayes <phayes@ai.uwf.edu>
- Cc: Patrick.Stickler@nokia.com, w3c-rdfcore-wg@w3.org
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