Re: rdf inclusion

>    [Sandro Hawke]
>    Here's a test case for rdf/daml inclusion:
> 
>       I have two RDF files of instance data using ontology
>       O1.  O1 is available on the web at two different addresses,
> 	 http://www.example.org/O1-a and
> 	 http://www.example.org/O1-b 
>       File a.rdf imports O1-a, file b.rdf imports O1-b, but are otherwise
>       identical.  The contents of O1-a and O1-b are identical.
> 
>       Is the meaning of a.rdf and b.rdf supposed to be exactly the
>       same for all systems, ...
> 
> This question would be better phrased as: "Are all systems supposed to
> draw exactly the same inferences from a.rdf and b.rdf?" 

Yes, exactly.

> I would
> tentatively answer Yes.  (I'm taking "supposed to draw" to mean "would
> be justified in drawing"; obviously, some systems will miss valid
> inferences others will make.)
> 
>       ... or are applications allowed to hard-code
>       "http://www.example.org/O1-a", along with perhaps some human
>       understand gathered from a telephone conversation between the
>       programmer and the ontology creator?
> 
>    My sense is that the string "http://www.example.org/O1-a" really is
>    special and can be hard-coded, along with ontology information which
>    is not machine-readable.   This feels more scruffy but more workable.
> 
> Can you clarify what you mean by "hard-coded"?  I'll assume you mean
> that some symbols in 01-a have procedural attachments that are missing
> in 01-b.  For instance, 01-a might verify (< 3 5) by calling a
> built-in "<" function, whereas 01-b might have to resort to using
> Peano arithmetic.  Of course, the fact that 01-a and 01-b are
> indistinguishable means that 01-a also has Peano's axioms, so the call
> to the "<" function just speeds the inference up.

Indeed.  Well said.  Thank you.

> The only way to get a difference between 01-a and 01-b is to give 01-a
> a procedural attachment that goes beyond what 01-b knows, leaving 01-b
> stuck when given any query of the form (< numeral numeral).  This is a
> possible scenario, so if it became common practice for different
> agents to make their own procedural attachments to symbols in various 
> ontologies I would have to withdraw my tentative Yes.  But let's get
> clear on what that would mean. Your phrase "along with ontology
> information which is not machine-readable" seems to indicate that 01-a
> does contain some specification that "<" is to be handled in a special
> way, but that this spec can't be read by all machines.  In that case,
> 01-a and 01-b would no longer be identical.  01-a would have this
> mysterious black box sitting in it that 01-b doesn't have.  In that
> case machines that can't penetrate the black box should refuse to use
> 01-a, and my Yes is restored.
> 
> The only way to get the difference you want is to have the information
> about 01-a's specialness reside *outside 01-a.*  Anyone anywhere can
> decide that 01-a is special to it in some way just because of its
> name.  But if you're going to allow that, why not have some agents
> omit all the assertions in 01-a that contain the symbol 'daml'; while
> others read 01-a backward and 01-b forward.  Meanwhile, 01-c, which
> contains only the assertion <> zen:enlightenment <zen:satori>, is
> interpreted by some agents as actually containing exactly the
> assertions of 01-b.  So, to agents in on the trick, 01-a and 01-b,
> which appear to be identical, are really completely different, and
> 01-b and 01-c, which appear to be different, are identical.  Can I
> have my Yes back?

I'd sure hate to see the look on your face if I said "No."    :-)

What happens when the thing included is 
   http://www.daml.org/2001/03/daml+oil
?  You can fetch some RDF from there, and it does constrain the terms
prefixed with that string, but it doesn't (and couldn't) contain the
axiomatic semantics which you'd need for the kind of behavior you want
with your "Yes" answer.  I guess this is just a bootstrapping problem,
and you can have your "Yes" in general.....

    -- sandro

Received on Friday, 26 April 2002 14:43:11 UTC