Re: ISSUE 5.6 - daml:imports as magic syntax

Dan Connolly wrote:
> 
> short version: please let's drop daml:imports altogether.

short answer: NO ;-)

For long answer, read on...

> 
> Elaboration:
> 
> I don't have any software that notices
> whether daml:imports is there or not.
> (well, it's treated like any other property,
> but I have never built nor used any applications
> that make use of that propoerty).
> Hence, I almmost never put it in my data files.
> 
> Does anybody else have software that pays
> any attention to daml:imports whatsoever?

In the SHOE software that Jim and I worked on at Maryland, imports was
an integral feature to the whole thing (although we called it
USE-ONTOLOGY) in SHOE. Without it, a semantic web user has absolutely no
way of saying what portions of the Semantic Web they agree to. It is
essentially a knowledge hyperlink, and thus removing it is like saying
"can we please take the <a href> tags out of HTML."

Although we've had this argument before in other threads in other
discussion groups, let me make another attempt at persuading you. The
question is, how do we combine distributed information in a way that two
parties can make "legally-binding" agreements on its meaning. Here are a
series of approaches:

1) The Paranoid approach - We don't combine anything. The only things
entailed by the document are those things that follow directly from the
document itself. This defeats any attempts at integration and puts us in
the same situation as stove-piped database systems

2) The Gullible approach - The entire web contributes to the entailemnts
of every document. Of course, that means we automatically believe
everything the Taliban, the National Enquirer, or Joe the computer
hacker says. In this world, I'll unplug my computer, take my money out
of the bank, bury it in a tin can, head for the hills, and wait for
someone to shut the entire thing down.

3) The Anarchist approach - The meaning of semantic web documents is
completely up to each application that processes them. These
applications are free to include any ontologies they wish when
determining the entailments of any documents. Of course, this means I
can choose to always include an ontology that says "P and not P" and
then provide you a proof of why you owe me your entire life savings.
This will lead to a semantic web that isn't interoperable, because you
have no basis for agreeing on the meanings of things.

4) The Engineering approach - We design the Semantic Web so that it
possible for people to make their assumptions and agreements explicit.
When I have an e-commerce transaction with you, I explicitly state what
assumptions are being made by commiting to an ontology (this is what
imports does). This ontology may in turn, commit to a whole chain of
ontologies that can be used in determining the meaning of the
transaction. We can completely define the semantics of this.
Essentially, if you accept a document, then you also accept the
ontologies it imports.

Note, this approach does not preclude applications from combining
ontologies in novel and interesting ways, it simply says that the
results are not necessarily the basis for shared understanding between
two parties who don't have any other prior agreements.

> Is daml:imports observable from a testing perspective?
> Are there any conceivable daml:imports tests that
> a piece of software could fail?

Yes. See Peter's example in a later message.

> Regarding the issue Jeff discusses...
> 
> On Mon, 2002-09-09 at 16:23, Jeff Heflin wrote:
> >
> > Problem:
> > --------
> > If daml:imports is just another RDF or OWL property, then users can
> > place restrictions, etc. on it. For example, consider a situation where
> > there was a max cardinality of 1 on imports. If an ontology imported two
> > or more ontologies, then this would effectively say that the ontologies
> > are equivalent.
> 
> Yes, exactly.
> 
> > It is probably best to avoid such situations.
> 
> Well, if folks don't mean that, then they shouldn't say it.
> But if they say it, why should we (i.e. implementors of OWL
> softwre) not deduce that they meant it?

Because we have to implement the language that we develop in order to
make it to recommendation stage. I certainly wouldn't know how to
implement something that allows that and has a clean semantics.

> > Possible Solution:
> > ------------------
> > This seems to indicate that imports should be a "dark" property.
> 
> That seems like an awfully expensive solution. It seems
> easier to put a "don't do anything silly" paragraph in the guide.
> 
> > Note
> > that this isn't an issue in the Abstract Syntax, since in it, everything
> > is essentially "dark." In Pat Hayes' recent OWL model theory, it should
> > be sufficient to say that owl:imports is not an instance of owl:Object,
> > owl:DatatypeValue, owl:Class, owl:ObjectProperty, or
> > owl:DataTypeProperty.
> 
> That much I can live with, but...
> 
> > However, it would still be an rdfs:Property, but
> > any RDF graph that uses it as a subject or object would not be
> > well-formed OWL/RDF.
> 
> Why go that far? If they say owl:imports is an owl:ObjectProperty,
> they've contradicted themselves. Too bad.
>
> Why stop them from contradicting themselves in this way, though?

I was just following the pattern Pat had used to describe similar "dark"
properties in his model theory. However, as long as owl:ObjectProperty
was explicitly disjoint with owl:Metadata (or whatever you want to call
the class that contains owl:imports), I suppose the contradiction
approach would be fine. At that point reasoners could just simply return
random results and still be sound with respect to the model theory. I'm
not wild about that though. If you give users enough rope, they will
hang themselves. 

> > Note, owl:imports doesn't fit into any of the
> > classifications in the table in section 2 of the Hayes model theory, so
> > perhaps a new classification called metaproperty or such is needed.
> 
> Poor choice of names.
> 'metaproperty' would make sense for something like cardinality;
> i.e. a property about a property. But imports isn't a property
> about a property.

Agreed. Maybe "ontology metadata" would be better?
 
> > Semantics:
> > ----------
> > It is important that the semantics of owl:imports be added to any
> > semantics documents.
> 
> Why? Could you please give the argument that this conclusion
> comes from?

Imports changes the entailments of an ontology. The semantics define the
entailments. Q.E.D.

> > To do this, we need to be able to refer to sets of
> > OWL statements (such as a web page, a database with an OWL interface,
> > etc.) This could probably be called a resource, but that term is also
> > used to describe RDF instances, so for lack of a better term, I will
> > choose the term graph for the time being. Let graph be a function from a
> > URI (URL?) to an RDF/OWL graph. Each OWL graph has a set of entailments
> > that are determined by the model theory. The semantics of a statement:
> >
> > A owl:imports B.
> >
> > are:
> >
> > if graph(B) |= X then graph(A) |= X
> >
> > (Note: Here, "|=" is the OWL entailment relation)
> >
> > One question is whether we need something more specific in the model
> > theory that, for example, uses ICEXT and IEXT.
> >
> > Any comments or suggestions?
> >
> > Jeff
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Tuesday, 10 September 2002 17:38:51 UTC