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

Summary: we still disagree.

To elaborate...

On Thu, 2002-10-31 at 08:42, Jeff Heflin wrote:
> Dan Connolly wrote:
> > 
> > On Wed, 2002-10-30 at 19:34, Jim Hendler wrote:
> > >
> > > [various stuff snipped]
> > >
> > > I've been avidly following this discussion, and also carefully read
> > > the dialog between Jeff and Tim Berners-Lee publicly logged at [1].
> > > I find myself torn - on the one hand, I'm certainly familiar with
> > > Jeff's work in SHOE and the use of something like "imports" to mean
> > > "Commits to" -- i.e. that I agree with EVERYTHING that some ontology
> > > (or set of instances or whatever) says, whether I link to it directly
> > > or not. On the other hand, I'm beginning to better understand what
> > > Dan (and Tim) are saying about maybe we want to allow more freedom to
> > > explore different commitment methods and the like.
> > >
> > > I would ask the following - if imports is an optional feature (we've
> > > already agreed it doesn't have to be used),
> > 
> > but it has to be
> >   -- implemented
> > not to mention
> >   -- tested
> >   -- specified
> >   -- explained
> > etc.
> 
> Implementing it is breeze.  What is is so complex about computing the
> "imports closure" of a document?

I didn't mean to say that the implementation burden of imports
was prohibitive; just that it's not free. i.e. just because
I don't have to use it in my documents doesn't mean it costs
me nothing.

> It is no more complex than deferencing
> a sequence of namespaces! Here's the pseudo code for a naive way to do
> it:
> 
> findImportClosure(doc)
> 
>   closure = doc
>   for each imports in doc
>     impClose = findImportsClosure(imports.importDoc)
>     closure = closure union impClose
>   return closure
> 
> If you wanted to be more efficient, you could keep track of which
> documents have already been included, and only include those that are
> not in the list, but that is also trivial.
> 
> > > and since anyone can
> > > invent their own term to explore a different commitment strategy what
> > > is the downside of including an imports statement of the type Jeff
> > > advocates?)
> > >
> > > For example, I am playing with something that looks a bit like this:
> > >
> > >   <> jim:commits
> > >     [jim:partialMappingTo foo: ;
> > >      jim:usingMappingRules bar: ] .
> > >
> > > in some recent research, and don't see where the existence of
> > > imports, which I won't use here, bothers me. I couldn't live with
> > > the meaning that referring to something in another ontology
> > > automatically had the strong implication that imports does (total
> > > agreement), but I have no real problem with one I don't have to use,
> > > but can if I want that particular meaning.
> > >
> > > So Dan, I guess this is to you -- why do you think including one
> > > particular imports method would be premature standardization?
> > 
> > Because specification of it involves connecting logic
> > with protocols in an unprecedented way.
> 
> But the group chose to embed logic in RDF in non-standard way that has
> delayed us by untold months, and who knows if the semantics will stand
> the test of time. If you were really concerned only about standardizing
> stuff that was well understood, we should have never taken that path.
> Imports is much cleaner and much more well-understood than how to embed
> a logic in RDF.

I disagree. RDF a funky syntax for the existential-conjuctive
fragment of FOL; to that we added a bunch of axioms; quoting
from my original Aug 2000 proposal:

<Property ID="inverseOf">
  <comment>for inverseOf(R, S) read: R is the inverse of S; i.e.
     if R(x, y) then S(y, x) and vice versa.</comment>
</Property>

  -- http://www.w3.org/2000/08/daml-ont.rdf

I don't see the "untold months" as a delay; I see it as the
work of this group, to get the details right.

> At least scores of ontology work have already done this
> in a non-Web context.

I might find that more convincing if you cited this
work so that I could study it myself.


> > ---
> > excerpt from
> > > [1] http://ilrt.org/discovery/chatlogs/rdfig/2002-10-30.html
> > 
> >  22:31:33   <timbl> I am saying that the functionality is useful but
> > here are many ways of doing it and you need a new model theory for the
> > web. I can write axioms for daml:imports using my log:semantics and
> > log:includes. But i think the community would wantto discuss al this. So
> > it shouldn't be core webont.
> > ---
> > 
> > And because I see so many places where the requirement
> > is met without using daml:imports.
> 
> And fine. You don't have to use it. But I suspect the reason you don't
> think you need it is because you don't actually share your data with
> anyone else's application.

Not so.

> You may publish it on the Web somewhere, but
> can you name another application independently developed by someone else
> that actually consumes your data and uses it for a useful purpose?

I share data among applications and tools like
  -- Mike Dean's airport scraper
  -- Jim Lay's image annotation and mapping tools
  -- the MIND group's authoring tools
  -- Euler
not to mention the variety of tools that probably
don't qualify as "independently developed".
  -- cwm
  -- various XSLT tools, like my circles-and-arrows stuff
	http://www.w3.org/2001/02pd/
  -- Zakim
  -- libby's squish query engine.

I'm certainly interested to hear about independently developed
tools and applications interoperating on the basis of
daml:imports.

> In
> order to reach agreement, you would have to tell them which ontologies
> and subsets of documents are relevant. How to you propose to do this?

They follow their noses from one document to another.
rdfs:seeAlso is one relavent mechanism, but there's
a variety of others.

> > And because, well, just because. i.e. because my
> > engineering experience tells me so. I don't expect this
> > latter reason to convince anybody else, but you asked
> > me for my position.
> > 
> > >  Would
> > > it help if we made sure that documents (all or some) made it very
> > > clear that this use of imports was optional?
> > 
> > No.
> > 
> > That wouldn't reduce the burden to specify/test/explain/etc.
> > 
> > And most importantly: it won't make it any easier to
> > remove it later if/when we find a better solution.
> > 
> > --
> > Dan Connolly, W3C http://www.w3.org/People/Connolly/
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Thursday, 31 October 2002 11:47:01 UTC