Re: WebOnt General Requirements Subgroup - Initial E-mail

>Pat,
>
>Sorry for the terse descriptions in the table, I had assumed that people
>could match these back to the documents that Deborah and I sent out
>earlier. Details on my list can be found at
>http://www.cse.lehigh.edu/~heflin/webont/reqs.html while information
>about Deborah's can be found in
>http://lists.w3.org/Archives/Public/www-archive/2001Dec/0022.html.
>Unfortunately the original list was created by Jim from the various use
>cases requested as "homework" so I don't think there is a single place
>that provides details on all of them. Of course, you may say that some
>of what we have is still vague, but that's actually part of our job.

OK, fair enough. Sorry if I havn't been keeping up with all the 
emails; for the first time in my life, I find it is physically 
impossible to actually read all my emails, even when the spam is 
filtered out.

>That being said, I'm will to clarify a little bit about what I think
>some of these mean. I simply see shared meaning as the requirement that
>we have shared ontologies, and that different sources can commit to the
>same ontology to express that they share definitions for terms.

OK, ta. Question for us to consider: does this amount to more than 
being able to import terms using URIs? If so,  how much more? For 
example, I suggested an 'imports' primitive to the SUO-KIF group, and 
it became clear in the subsequent discussion that people wanted to be 
able to distinguish between 'importing' an ontology wholesale (ie to 
effectively include one set of axioms in another by naming the set, 
maybe with a URI); 'importing' an ontology as a set of definitions 
(where the imported terms may be used in the importing ontology but 
not redefined or restricted in their meanings, in some sense); 
'importing' in the sense of extending a namespace but not importing 
any content; and even some variations on these, eg importing a 
concept plus its definitions, but re-naming it in the importing 
ontology. The resulting syntactic complexity needed to distinguish 
all these cases seemed rather worrying; people felt that the proposal 
was getting out of hand in the SUO-KIF context; but maybe there is no 
way to avoid these complexities on the web.

>As for
>ontology reusue, I simply see this as the ability to have ontologies
>reuse or extend other ontologies.

I don't quite see how this is distinguished from sharing. Isn't 
sharing an ontology simply a form of re-use?

>As for ontology evolution, I see this
>as dealing more with changing an ontology. For example, if the old
>ontology said that "A whale is a fish" then we might want to change the
>ontology to fix our mistake. I see this requirement driving the need for
>distinguishing between different versions of ontologies and for data
>sources to commit to specific versions.

OK, ta.  But again, the issues seem connected. Eg suppose that the 
importing/sharing technique allows one to import part of an ontology; 
then this provides a way to 'change' the ontology - ie create a 
changed version, in a sense, of the ontology - by importing part of 
it and adding this to a different extension. There is a completely 
different set of issues connected with the regrettable fact that URLs 
are labile, and the same URL might identify a different ontology 
today from the one it identified yesterday. That is where 
'versioning' seems to come in, if I understand that term in a 
database sense. And that, again, seems to be connected with issues in 
the logical structure of the language, eg should it be rigorously 
monotonic? (Yes, BTW :-)

>I agree that expressiveness is important, but wonder if that might be
>too vague to be useful.

I think it is central in the design of any ontology language. The 
entire DAML+OIL effort so far has been largely driven by the 
requirement that the language provide an operational sweet spot on 
the expressiveness/deductive-tractability tradeoff; hence the central 
emphasis on description logics as a basic framework. Many of us 
however have either no particular interest in provable deductive 
tractability, or are willing to risk deductive incompleteness in 
return for expressiveness and a more elegant proof theory. Should 
WebOnt continue along these lines, or should we choose a different 
position on this spectrum?

BTW, heres another topic that seems to cut across everything else and 
seems central, though it's not a use requirement exactly: to get a 
proper, adequate, semantics for URIs. Right now we treat URIs as 
though they were simple logical names, but they obviously are not 
simple logical names, in general. URLs (or the corresponding 
fragments of URIs) are more like file names, for example. I think 
that creating a proper semantics for URIs is actually a very tricky 
problem that might have many repercussions on other topics on the 
list, eg it would have to come to terms with following enigmatic 
sentence from RFC 2396, which practically has 'versioning' branded on 
its forehead:

"The resource is the conceptual mapping to an entity or set of
          entities, not necessarily the entity which corresponds to that
          mapping at any particular instance in time.  Thus, a resource
          can remain constant even when its content---the entities to
          which it currently corresponds---changes over time, provided
          that the conceptual mapping is not changed in the process."

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 10 December 2001 18:29:02 UTC