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

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

Then I didn't understand/get the latest proposal.... Pat's rewriting will help (I see he just sent it out, so I'll reply more
precisely on that, meanwhile on to the rest of the email).

> > 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.
MMmm, that's precisely the point and not a red-harring (even, it seems like it's the only point, given that we agree on point 1,
i.e.  that it's bad to keep the import info out of the rdf graph).
If you can convince me otherwhise I'll be with you :)
You mention updates in the database setting (ahem....): in the database setting, but everywhere too (programming languages), the
topic of giving a semantics to update, or "assert"'s (maybe a better parallelism given what we're doing here) has always been one of
the hottest boiling potatoes ever. They are always considered as ugly non-logical features, that have to be accommodated just
because of users' needs (precisely what we're doing here... ;), ending with update semantics that are usually just operational (or
have to struggle against stratifications and monads....).
In this case, there's no magic wand too: defining the semantics using directly "references" in the entailment process gives you just
an (natural language) operational semantics. As said, I guess Pat will struggle with this when having to give a formal definition of
the "logical import", you/we'll see...
On the opposite, a light-flavor operational import would likely solve people's need, and not complicate the entailment process.

Restated:
  why should not we adopt a light operational import, given that it solves the primary needs that
  motivate this issue (import things, other than having to copy/rewrite them?), without touching
  the core definition of entailment?

I think that's the real question that has gone unanswered so far. It's not that a logical import would be a disaster or so, I
understand its merits, but it's just a matter of cost/benefit. If people can be convinced
that the logical update, along with its drawbacks, gives substantial advantages over the operational import, than I think we will
all be more than happy to support it. Otherwise, people will keep on being skeptical on the real needs of goind beyond a
simple-and-already-there rdfs:seeAlso.

-M

Received on Friday, 8 November 2002 13:40:15 UTC