RE: MT for imports (was: Re: Imports Proposal)

> Yes, that's a pattern W3C uses to deal with trust issues
> around our tech reports/specs; I can see it getting
> used for ontologies too.

The problem is, without some way to point to the thing you
want to use, you can't even do this.  The user needs to be able
to state an intention.  I prefer to have some minimal way
to state that intention explicitly.  Without overloading
the namespace declaration.

You are happy letting a thousand flowers bloom with a 
variety of implementation dependent mechanisms. 

I don't have experience with the previous attempts at this, 
so possibly I am being naive, but I have not been convinced 
of the difficulty of providing a very basic mechanism that 
does not conflict with the 1000 flowers solution (you 
can always leave out owl:imports).

- Mike

Michael K. Smith, Ph.D., P.E.
EDS - Austin Innovation Centre
98 San Jacinto, #500
Austin, TX  78701

* phone: +01-512-404-6683
* mailto:michael.smith@eds.com


-----Original Message-----
From: Dan Connolly [mailto:connolly@w3.org]
Sent: Wednesday, November 13, 2002 10:36 AM
To: Smith, Michael K
Cc: Jim Hendler; Pat Hayes; Jeff Heflin; www-webont-wg@w3.org
Subject: RE: MT for imports (was: Re: Imports Proposal)


On Wed, 2002-11-13 at 10:22, Smith, Michael K wrote:
> 
> >If the WG decides to go with one of these import closures things (and 
> >Pat's examples below show yet more reasons I worry if we've got it 
> >right) we need to make sure we handle cycles in some correct way.
> 
> Which is why all of the serious proposals compute the transitive closure
> of imports.
> 
> Re Pat's questions.  I think they are not at this time our concern.

It seems to me that either they are our concern at this time
iff imports is our concern at this time.

> I thought we had explicitly rejected dealing with things like webs of
> trust.  Neither should WE be worrying about issues of cache coherency.
> Someone will have to, just not us. 

To me, that argues that we should postpone imports.

> This is another reason why I prefered not getting entailment involved 
> in the details of imports.  As Pat's examples point out yet again, 
> imports keeps bumping into these fundamentally operational issues.
> 
> In order to address the problems that Pat raises, I suspect (guessing)
> that the distributed ontologies that work will use naming conventions
> to create versions.  That is, wine.owl will start out linked to
> wine_v_1.owl.
> As the wine ontology evolves, wine.owl will be linked to the successive 
> versions.  If I am extending wine.owl and am concerned about change 
> to the underlying ontology, I will import wine_v_1.owl, not wine.owl.

Yes, that's a pattern W3C uses to deal with trust issues
around our tech reports/specs; I can see it getting
used for ontologies too.

> What we want to provide is some minimalist scaffolding that can be used
> for initial experiments in how to build distributed knowledge bases.

Eek! No! DAML+OIL and OIL and Protoge and SHOE and ...
provide scaffolding for initial experiments.
(and based on those experiments, I think it's not yet cooked.)

Our job is to produce a W3C Recommendation; there
was a time when W3C put the 'Recommendation' label
on 'initial experiment' specs, but that time has long
gone.

"W3C considers that the ideas or technology specified by a
Recommendation are appropriate for widespread deployment"
 -- http://www.w3.org/Consortium/Process-20010719/tr.html#Recs

If our spec has stuff that we consider 'intial experiment'
material, then it has to stay at CR until we've demonstrated
sufficient implementation experience to make it
'appropriate for widespread deployment.'

I'd like to work on imports design and deployment
*after* we release OWL v1, not squeeze it into
the next few months.

> 
> - Mike

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Wednesday, 13 November 2002 12:17:14 UTC