Re: LANG: owl:import - Two Proposals

Jeff Heflin wrote:

> Hi Jonathan,
> Please see my responses below.
> Jonathan Borden wrote:
> >
> > I've suggested what may be an alternate approach, or simply a wrinkle on
> > in
> Oh yes, sorry I missed that. I would probably consider it a wrinkle on
> proposal #2. In particular, it has the same syntax, but a slightly
> different semantics. However, I think all of the cons of proposal #2
> still apply to it. Also, I do not think a processing model is a good way
> to specify these semantics. In particular, it says in order to be OWL
> compliant, you must implement things a certain way, which discourages
> creative solutions that might have the same effect. I'd much rather give
> semantics (i.e., what is the thing supposed to mean) and let
> implementors have the freedom to decide what works best in their own
> systems.

In general I would agree. Importation/inclusion is an exception. What I want
it to _mean_ and what I want to _happen_ are identical: when <owl:import
rdf:resource=""/> is used,
"http//" should be dereferenced, and any triples found
there merged into the current KB. This is really pretty simple.

> > Regarding your objections:
> >
> > [[
> > 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.
> > ]]
> >
> > I'm unsure how to interpret this statement. I would say that the OWL
> > processor should include triples obtained by retrieving and parsing the
> > _object_ of an owl:imports statement, into the current "graph", but that
> > URIref ought be retrieved and/or parsed only once.
> >
> > Is that 'semantics' undefined? (seems precise enough for me :-)
> Note that the undefined semantics is not for things of the form
> A imports B
> but instead of the form
> foo subClassOf imports
> A foo B

I never suggested that anything that was a subClassOf imports ought be
treated as an import, the proposal is very specific: when the "owl:import"
predicate is encountered ... I mean literally this, not something that is a
subClassOf, has the same class extension of, is equivalent to etc. Are we
unable to be very specific?

> We can come up with all kinds of examples along this theme that lead to
> nightmares for implementation (imagine where I import something that
> then says that another property I have is actually a subclass of
> imports, then I have to import a whole new set of things, which in turn
> might have other subclasses of imports). That's why proposal 2 suggested
> that anything that has imports as a subject or object be undefined.
> However, if we do this, some tools might decide to do some inferences
> based on it, others might do a different set of inferences and still
> others might consider it invalid syntax. If people start relying on the
> processing aspects of their favorite tools (which they tend to do, see
> web pages and web browsers as a case in point), then we have reduced
> interoperability by not saying what all valid syntactic constructs must
> mean.

This is not a problem. You can give "owl:import" a meaning, subclass it, and
do whatever you wish to it. We should specifically say that if owl:imports
_itself_ is encountered, this is what happens.... the URI is dereferenced
and any triples found there merged into the current graph.

Perhaps you are suggesting that importation reduces interoperability. If so
we can decide whether to have this feature of our language. I think it is
worth it as specified above.

> >
> > [[
> > - 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?
> > ]]
> >
> > Fair question, and one open for discussion. I'd say that regardless of
> > subject, the object be imported into the current graph/KB.
> Note though that this is a question that does not come up if we do
> proposal #1. We only have to answer it if we go with proposal #2.

Err, yes, but that's why different proposals are different, because they
have different issues.

> > [[
> > - The fact that an ontology's classes and properties do not occur
> > between the <Ontology> tags is unintuitive
> > ]]
> >
> > Oh well. That's an artifact of the decision to use RDF, however we
> > to use RDF/XML at F2F 2.
> Sure this isn't a deal-breaker, but because of it, proposal #1 has the
> advantage of us not having to constantly answer the question "So tell me
> again why the contents of an ontology are described outside of the
> <Ontology> tag?"

Fair enough. We could also use the owl:Ontology tag _instead of_ rdf:RDF if
that would help. This has nothing per se to do with owl:import does it?

> > [[
> > - 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.
> > ]]
> > Maybe, but what is the functional significance of this, and what
requires us
> > to use rdf:about=""?
> >
> If we are using RDF triples for everything, then triples that say
> something is of type owl:Ontology and that that something imports
> something else need a subject. In particular, this subject should be the
> same for all such triples that concern the same ontology. The use of
> about="" is a quick and dirty way of saying "use the base URL of the
> document, since this should at least be different from the URIs of other
> ontologies." Once again, this isn't huge; so far it hasn't seemed to
> cause significant problems in practice with DAML+OIL. However, it
> contributes to the difference between a language with an elegant design
> and one that appears to be cobbled together. Which I think is one of the
> most important factors in acceptance.

Languages that are designed by committees often aren't as elegant as those
designed by an individual. I'm sure that you could go off and design what
you consider the perfect ontology language and it would be elegant. There is
no doubt that having to design a language in terms of triples causes
artifacts. If everyone in the group had decided instead to design a language
in XML or some other syntax ... oh wait, wouldn't that be KIF?

Seriously though, this is entirely a different issue than owl:import, should
we revisit the decision to use RDF/XML as the exchange syntax of OWL? All I
am saying that if we have decided to use this as a syntax then let's use it
and move on.

> > [[
> > - 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.
> > ]]
> >
> > Perhaps, but is the ability to recognize the boundaries of merged
> > a requirement, or objective? That's to say, is meeting the above
> > goals worth major changes to the OWL syntax, ones that go against RDF
> > compatibility?
> You are right, recognizing the boundaries of merged ontologies is not an
> explicit requirement or objective. However versioning, which I mentioned
> above is (R6). I also believe that it is important for robust models of
> explicit ontology extension (R3) and commitment to ontologies (R4),
> although I recognize that not everybody agrees with me on this point.
> More important though, is when the Semantic Web gets to matters of
> trust, it will be essential to know which statements come from which
> documents. Even though our WG is not doing anything about trust, why
> should we make design decisions that we know cannot be extended by later
> "layers" of the Semantic Web? Let's think ahead a bit, and not make the
> job of the next WGs as difficult as our job has been.

he he. We don;t have a trust model/framework so it is really hard to make
these sorts of decisions. You assume that trust will be somehow computed. I
might assume that trust will be a function of the base URI of the
ontology -- perhaps trust will be computed on the source document/graph
prior to inclusion processing? who knows? It is hard to let such nebulous
requirements affect the concrete decisions we need to make today.

> > It seems that this issue is a general one with software modules e.g.
> > they are compiled together, it's hard to know what came from where
> > out of band information, such as used by debuggers, is included. Yet
> > C++ is ANSI C++.
> But the Semantic Web is a lot more like distributed components than it
> is like a compiled C++ program.

True, but we can make a workable <owl:import> if we treat it as a compiler
would. The name of the game at this point, in my mind, is making something
that works and meets our objectives with as little work as is necessary.


Received on Friday, 4 October 2002 08:12:50 UTC