Re: rdf inclusion

I must apologize for joining the discussion on a list I don't keep up 
with.  I was looking to answer something else I had been pointed to and 
my mailer displayed this one first.

On Wednesday, May 8, 2002, at 02:34 PM, Jeff Heflin wrote:

> Pat Hayes wrote:
>>
>>> Jeff Heflin wrote:
>>>>  ... Since I was the initial proponent of daml:imports on the Joint
>>>>  Committee, let me address this issue. You are absolutely correct 
>>>> that
>>>>  the imports statement must be used. Simply refering to a namespace 
>>>> does
>>>>  not include any ontology definitions. You must make the imports
>>>>  statement explicit. Period. ...
>>>

Neither half of this is correct by itself, IMHO.  Each is too sweeping.

When you use a term (eg Property) in a namespace, its meaning is defined
by the definer of that namespace.  You are (unlike in english)
bound to use a term according to its creator's definition.

The specifications of HTTP are defined such that if you dereference
a term, then the information you get, modulo forgery, is  a published
statement about the term by its owner.

The information which anyone may get in this way may be useful,
When you use such a term, you can be held to the implications of
your statements according to the specifications. When the term's owner
publishes a schema, then this makes public a currently rather
poor subset of the information about the term.

You certainly don't have to explicitly import the schema or anything
else to be bound by the meaning of the term.

However, that doesn't mean that every processor should consider your
document as containing the statements of the schema.  An inference 
engine should generally feel at liberty to suck in such information IF 
it exists, and IF it is of
a form which will be useful.  But it is not part of the document.

So it is maybe useful to have a statement which asserts that the 
document's
meaning explicitly includes a given resource's meaning.   It isn't 
essential
at the RDF level.  Shouldn't be part of the core.
If it is an RDF statement (rather than magic syntax) then it becomes
interesting because it gives web access capability to an inference 
engine.



>>> So, what does it mean if one refers to a term in an ontology
>>> without importing it? Should this be considered an error?
>>
>> I would say not.
>>

Agreed.

>>>  If
>>> so, is there a reasonable recovery technique, like ignoring
>>> triples using externally defined terms not imported?
>>
>> In RDF, the official line (as I understand it) is that any published
>> RDF which uses a term is (asserted by the publisher of the RDF
>> document to be) a true assertion, and anyone who draws any RDF
>> conclusion from any combination of such RDF is entitled to conclude
>> that the conclusion is true also. That is, publication is assertion,
>> and all assertion is unqualified. There is no way to explicitly agree
>> or disagree with another piece of RDF.
>>

It is very important to define, in the language specification, what a 
document means. However, that doesn't mean that an agent should or must 
or is even entitled to believe anything which is found on the web.

Every agent needs somewhere to start.  This is normally given to it when 
it boots
or runs from the command line or whatever.

There are many ways to agree or disagree with another piece of RDF.
RDF by itself isn't quite complete enough (it needs eg N3 formulae)
but you can certainly state that a document is true (parses to a true 
statement set)
in pure RDF.

There are some conventions which ground things.
A home page of a company or person is considered asserted.
An email sent is considered asserted.
But I am forced to conclude (look at archive.org) that you can't
take every page you get from HTTP as being asserted by the
domain owner: the only way you can derive information
from it is indirectly from something else (a semantic link, if you like).

This is a weak spot in the web architecture.  HTTP headers have been
proposed to fill it, but I think we will get by without.

>>>> ... The problem with using RDF namespaces to decide which schemas are
>>>>  relevant is that multiple files may contain different definitions 
>>>> about
>>>>  the same URI.
>>

Umm.. there is one namespace document.  Other people may proffer other 
statements about RDF vocabularies or the price of fish for that matter, 
and whether you use them as input is rather up to you.

>> Indeed, but RDF is designed to work in a more perfect world where
>> people do not disagree about definitions. Or at any rate, it
>> delegates responsibility for dealing with such conflicts to some
>> other mechanism.
>

In fact, RDF's start was in metadata, and metadata started with PICS 
which was all about implementing a world in which people disagreed about 
each other's  definitions.

> This is exactly why RDF as-is is not appropriate for the Semantic Web.
> It really wasn't designed for the problems of a distributed,
> heterogeneous information environment.

That actually isn't true.  It was specifically designed for such an 
environment.

> There is no way we can get the
> entire world to agree on the definitions, so our architecture must
> accomodate differences of opinions.
>

Absolutely.

> The RDF specs never discuss how one combines information from multiple
> sources. It is implied that you simply merge all of the graphs.


No, the RDF spec defines the ability to merge graphs and no other.
Just as a machine code gave one add and subtract and no multiply,
it doesn't mean one can't do fancier things on top.

> This
> isn't too bad when you can't express a contradiction, but once you
> include additional semantic primitives (as DAML+OIL does) and scale for
> use in distributed environments you are bound to get contradictions if
> you simply merge the information sources. Some have suggested that in
> such situations that you just select one of the contradictory axioms and
> throw it out. However, if different systems choose different things to
> throw out, then they no longer agree on the semantics of terms used. The
> only way around this problem would be to have a consistent, world-wide,
> determinisitc method for resolving these contradictions. Even if it was
> possible to design such a thing, it would be highly impractical because
> people often cannot agree on things (some of the worst cases of this
> lead to wars, etc.) We can never expect the Semantic Web to be a single
> consistent knowledge base!
>
You are absolutely right in that.  RDF was never expect to imply that, 
and in fact a whole lot of energy has been expended from time to time 
explaining that to people.

RDF provided only reification as a very crude tool for doing fancier 
things.  I found that allowing an RDF set of statements (graph, "model" 
for some, or better "formula") to be itself gets you out of that hole, 
and allows you to handle a heterogeneous world

> Jeff

Received on Wednesday, 22 May 2002 23:24:29 UTC