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

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? 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. At least scores of ontology work have already done this
in a non-Web context.

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

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

Received on Thursday, 31 October 2002 09:42:37 UTC