Re: Fwd: Re: LANG: owl:import - Two Proposals

Jim Hendler wrote:
> 
> This one also
> 
> >Sender: heflin@EECS.Lehigh.EDU
> >Date: Wed, 02 Oct 2002 12:07:36 -0400
> >From: Jeff Heflin <heflin@cse.lehigh.edu>
> >Organization: Lehigh University
> >X-Accept-Language: en
> >To: Jim Hendler <hendler@cs.umd.edu>
> >Subject: Re: LANG: owl:import - Two Proposals
> >
> >Jim,
> >
> >Here's another one I think you sent only to me. If you meant to send it
> >to  the mailing list, please do so and I will respond there.
> >
> >Jeff
> >
> >Jim Hendler wrote:
> >>
> >>  Elsewhere Jeff asked if those who prefer proposal 1 could address the
> >>  disadvantages of 2 - here's that addressing
> >>
> >>  >
> >>  >
> >>  >Proposal #2
> >>  >-----------
> >>  >Syntax:
> >>  >The imports syntax is in the domain of discourse of RDF, but not OWL.
> >>  >Essentially we have a class called owl:Ontology and a property
> >>  >owl:imports which can hold between a pair of Resources. Statements
> >>  >are made about the current document using an empty URI reference
> >>  >(this assumes that this expands to the current URI context).
> >>  >The meaning of any statements which include
> >>  >owl:imports as a subject or object is undefined. Syntactically, this
> >>  >approach is the same as that of DAML+OIL. For example:
> >>
> >>  >[snip]
> >>
> >>  >
> >>  >(where merge is as defined in the draft RDF model theory [1]).
> >>  >
> >>  >Pros:
> >>  >- It is possible to query an RDF graph to obtain information about
> >>  >what resources are ontologies and which ontologies import others.
> >>  >
> >>  >Cons:
> >>  >- Having valid syntax that has undefined semantics may lead to reduced
> >>  >interoperability. In particular, some users may build ontologies that
> >>  >rely on the arbitrary decisions made by their favorite tool vendors.
> >>
> >>  yes - but all langauges have some of these undefined, and we already
> >>  have them in our language unless we go to the strong model Peter
> >>  proposes in which case it is not an OWL document unless a particular
> >>  schema validates it -- As I've said often, my opinion is that that is
> >>  unworkable in the wild.  I don't see where there is a problem to say
> >>  it is undefined to  doing something that is unlikely to be done
> >>  anyway (i.e. subclassing owl:ontology info or changing it's rdf:type)
> >>
> >>  but, if some user community finds a reason to do this, implements it,
> >>  and a bunch of people find it useful - then it means the "Owl 2.0" WG
> >>  should look at it -- that's how web languages evolve, and I think it
> >>  is tremendous hubris on the part of our group to think we'll get it
> >>  "right" the first time.

I've already discussed this to some extent in [1]. I guess we have a
difference in opinion about standards design. I think we should be as
explicit as possible about what any valid syntax means. If we find a
better meaning for it, then we can release a new version that "get's it
right." You seem to be saying, if we're not sure about something, leave
it open, because you think it will be easier to change from a "we don't
care" to a "do this" than from a "you must do A" to "you must do B."

[1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0014.html

> >>  >
> >>  >- It is unclear what it should mean if a document C contains the
> >>  >statement A owl:imports B. Should this be another undefined construct?
> >>  >If so, how can you determine from a graph if the subject of an imports
> >>  >statement is the URI of the document from which the imports statement
> >>  >comes?
> >>
> >>  I don't understand this.  We would have a graph which includes the
> >>  statement in the graph that
> >>
> >>  :thisDocument owl:importants foo:thatDocument.
> >>
> >>  this would be useful for people who want to handle name space
> >>  extractions and the like.  But rather than arguing this at length,
> >>  let me say that the alternative -- imports not appearing in the graph
> >>  -- certainly provides LESS information than having it.

The issue is not whether the triple appears in the graph, in proposal #2
it would of course. The question is the semantics of this. The question
is, if a document C contains an imports statement who subject and object
are two different documents A and B, respectively, then should B's graph
be imported into A? I would think not because this would seem like a
major security flaw. However, if the semantics depend soley on a A
imports B triple for deciding whether or not to import something, there
is no way to prevent this because there is no way to know if that triple
comes from document A or document C. This is a critical issue! Without a
solution to it, proposal #2 is severely broken.

> >>  >- The fact that an ontology's classes and properties do not occur
> >>  >between the <Ontology> tags is unintuitive
> >>
> >>  I don't disagree with this - but again would ask about instance data.
> >>  I strongly resist having instances HAVE to be in an ontology context
> >>  (because they may be created by tools that are not OWL aware or are
> >>  hand generated - i.e. we create a lot now using the tool "emacs"
> >>  which is a great OWL instance creator (esp. using the DAML mode).

As I've said before, in proposal #1, instances have a <Data> tag that
corresponds to the <Ontology> tag. Therefore, they don't have to be in
an ontology context.

> >>  >
> >>  >- The use of about="" to make statements about the enclosing document
> >>  >seems like a hack. In particular is seems like we could be confusing the
> >>  >notion of a document that describes an ontology and the concept of an
> >>  >ontology itself.
> >>
> >>  I agree, but the problem is the only alternative you offer is to make
> >>  the notion of the document and the ontology be indistinguishable,
> >  > which to me defeats a lot of what I think the SW is all about.  I
> >>  would rather see us actually define what an ontology is (see my
> >>  earlier message in the previous thread about having an explicit
> >>  ontology statemtn with a list of the URIs it contains) which would be
> >>  a far more elegant solution to this particular problem which would be
> >>  better than either of the two proposed solutions here -- it didn't
> >>  get enough traction in the WG to be reintroduced here - my point
> >>  being we've already rejected an approach that would solve this
> >>  problem better than proposal 1 does, leading me to believe the WG
> >>  doesn't see this as the critical issue.

The proposal you mention had a problem which I responded to. It doesn't
actually identify the contents of the ontology, just some classes for
which it might have partial descriptions. I would be okay with a similar
approach if it actually associated the content (the individual
statements about classes and properties) of the ontology with the
ontology itself. I don't believe this can be done in RDF. Proposal 1
says, there are some things that cannot be directly expressed in RDF so
we'll have some additional information that is about our RDF.

> >>  >- The approach only partially succeeds in its goals, because although it
> >>  >represents ontologies and their properties, it loses the ability to
> >>  >recognize the boundaries of an ontology (i.e., what it contains) as soon
> >>  >as two or more graphs are merged together. In particular, if this
> >>  >approach is extended for use with versioning, then we lose the ability
> >>  >to know which statements come from which version of an ontology.
> >>  >
> >>
> >>  I agree, but again if this is what we want critically, we have
> >>  seevral good non-document ways of doing it, which the WG hasn't
> >>  seemed excited by.

I still haven't seen any good non-document ways of doing it.

Received on Thursday, 3 October 2002 10:56:11 UTC