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

Well, the way out here, between the two positions, would be the rfc2119-may (or rfc2119-should) version of the operational import.
Note this includes "totally free" weak solutions like the rdfs:seeAlso, that could be the temporary way out of all these hustles for
v1.

-M



> -----Original Message-----
> From: www-webont-wg-request@w3.org
> [mailto:www-webont-wg-request@w3.org]On Behalf Of Jeff Heflin
> Sent: Thursday, October 31, 2002 3:43 PM
> To: Dan Connolly
> Cc: Jim Hendler; www-webont-wg@w3.org
> Subject: 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 10:06:33 UTC