Re: LANG: need to CLOSE Issue 5.6 Imports as magic syntax

Massimo Marchiori wrote:
> 
> > Considering that we have a solution that addresses the requirements,
> > that simply clarifies things from DAML+OIL, that is a common element of
> > ontology design, and that does not restrict us from developing
> > alternative approaches in the future, I can see no good reason to
> > postpone the issue. I think that anyone who opposes this solution should
> > come up with an example of an application that it breaks or a specific
> > language extension that it will prohibit.
> 
> The reason for opposing that solution has been addressed already, e.g. among various posts, in
> http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0061.html
> http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0029.html
> http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0019.html
> http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0382.html
> 
> which I'll summarize, again, with:
> 1) [major] when transporting/manipulating RDF, you risk to lose the import information.

In the proposal, imports information is maintained as RDF triples. I
don't see any risk in losing it.

> 2) [moderate] owl entailment would depend on the timed web structure
> AFAIK these critique haven't been addressed yet. In particular, there haven't been unanswered objections to the "operational import"
> proposals, in their various form (rfc2119-flavors with explicit owl:import, or rdfs:seeAlso). Until there is a proper comparison and
> analysis, I don't think we can easily move forward.

This is a red-herring. Everything on the Semantic Web is time-dependent.
If you reason about a set of RDF statements, there is a good chance that
the page you got them from changed while you were reasoning. That is a
fact of life in multi-user systems. Of course database folks have
studied these problems for decades. They talk about properties such as
consistency preservation and serializability. We can think of an web
page update as a database transaction, and we can easily serialize these
updates. Thus, as far as time is concerned there is nothing here that is
any different from databases.

Jeff


> 
> -M
> 
> ps Note the "closure" thing is in all orthogonal to the issue: any reasonable version of import would include a closure notion of
> some kind (like in all import I can think of in any programming language....); this was never the real issue (no? ;)

You missed the point. The "closure" is a semantic way of getting your
"operational import." It has the exact same effect but is written in
such a way that people are not forced to use a particular algorithm. In
essence, by defining the closure, we can "include" all of the imports
before computing any entailments. Isn't this what you were in favor of?
Would not you operational definition be one algorithm for achieving this
definition? If you disagree, could you point out a semantic difference
between your operational imports and the "import closure" proposal?

> pps In case there's no consensus, note I would not be opposed to the (at that point, reasonable) "leave import after v1" proposal
> that DanC and Jim are advocating.

Received on Thursday, 7 November 2002 11:41:10 UTC