Re: ISSUE 5.6 - daml:imports as magic syntax

On Tue, 2002-09-10 at 16:38, Jeff Heflin wrote:
> 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.

I've been operating under the assumption/policy that if you use
somebody else's properties, you agree to their definition.
WorksForMe(tm).

> 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.

Well, this explanation is sorta appealing, but it doesn't tell
me enough to code it up. [perhaps you did, I see, upon
reading more closely.]

Can you point me to the code the implements USE-ONTOLOGY?

Can you explain how, if you took that code out, users would lose?

> > 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.

i.e.

|For example, suppose the URI foo pointed to an OWL KB that entailed x,
then
|the OWL KB
|
|        Ontology ( imports(foo) )

Hmm... to be a bit more explicit, say:

KB1:

  :Dog rdfs:subClassOf :Anmial.

KB2:
  :fido rdf:type :Dog.
  <> owl:imports <KB1>.

and from KB2 entials
  :fido rdf:type :Animal.

And it sounds like Finin (10 Sep 2002 16:56:23 -0400)
has some software that agrees. Any details, Finin?
pointers to code or whatever that I can try out?

I'm still not sure how to formalize it, but I suppose
that's a certain amount of evidence that there's a
design that we could deploy interoperably.

Elsewhere in this thread (10 Sep 2002 17:48:44 -0400), you say:

| I wasn't suggesting that ontologies should be in the domain of
| discourse. I'd actually prefer that they weren't.

Yikes! How do we give them titles, dates, authors, etc.
if we can't talk about them? Maybe you mean to distinguish
ontologies from ontology documents or something? I don't
think I understand you.

Back to the design details...

> > 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.

I suppose cleanliness is in the eye of the beholder...

> > > 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?

Umm... ok...

> > > 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.

Well, that begs the question. Why do imports change the entailments
of an ontology? (this is basically the same question as:
what would SHOE users lose if you took out whatever
code handles USE-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)

Hmm... maybe I didn't read that closely enough the first
time... I suppose that's a reasonably detailed design after all.

In N3, I could write that as:

  { ?A owl:imports ?B.
    ?A log:semantics ?AG.
    ?B log:semantics ?BG.

    ?BG log:implies ?X }
   log:implies { ?AG log:implies ?X }.

but I'm not sure cwm would do very much with it. Hm...
Jos, would Euler exploit that sort of rule in
the intuitive way?


> > > 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 18:15:00 UTC