Re: WOLREQS: Draft requirements document

I think we have included a number of things that are requirements for an OWL system not just for pure language.
r1 for example - shared ontologies - that is a requirement for applications and not for the language,
r3  ontology evolution - that is a requirement for ontologies over time and not just for the pure language.
these and explanation have some impact on the language extensions.
I would not put all of the functions that we are looking for in any of these requirements in the core language.
for explanation, it is very useful to be able to annotate terms with both if the information is told vs. derived, if told what ontology(ies) it came from, if derived how derived,  if derived, if it was derived using default info
or "hard/fast" rules.

if we were considering proof checking, explainability is a necessary precondition to proof checking.

also, as i input explanation into classic, we found that it was important to know -
the source of told information (what ontologies things came from)
if information was told or derived
if it was derived how it was derived
we provided a way of rerunning deductions and annotating structures.  It does not have to be done that way, but that was a useful approach.

in a new world of the web, derived information needs more support since it may be derived exclusively from information from authoritative sources or some from authoritative sources and some from other sources.
also, it could be derived from default rules or from hard/fast rules....

and for whether it absolutely necessary for owl, most of our requirements are not absolutely necessary for all use cases but are absolutely necessary for some use cases.
I would claim that explanation is absolutely necessary for use cases for intelligence analysts, help desk applications, and configuration, among others.

all of our other requirements  have the same property -
some use cases will use base ontologies without extension - meaning r2 is not absolutely necessary.
some will use proprietary ontologies that may not be modified and thus have little need for r3 and no need for r4
many web ontology uses do not use deduction and thus do not need r5 - inconsistency detection - or just work in such contradictory environments that they do not care about r5
some applications use small ontologies and have small or medium size kbs and thus do not care at all about r6
some have trained users or are backend systems for other systems and thus do not need r6 at all

some have no need for xml and thus have no need for r10
i doubt if many applications do not need search  but some dont need much other than text search thus having small needs for r12

many web applications need very simple ontologies thus expressiveness r14 is definitely not absolutely necessary for all applications...


Also, I am ok listing first the requirements that had consensus  but
i would not want to take the initial vote with a very heavy weight since i think votes were made before discussion or further description/defense was made for some of the requirements.

actually i think all of them have validity but the ones that did not get consensus were basically not clearly articulated by themselves or in separation from other requirements.

since time is short, i am willing to have the separation that we have:

a list with details of the requirements that have consensus by meeting time.
a list of requirement descriptions for the other topics so that at least we do not loose the work to date prefixing this list with other desirable requirements.

i made the third category - other requirements emerging from other groups since we will be responsible ultimately for collecting the requirements and those clearly emerged from that group.

on format,
i didnt know how to have the netscape mailer do the wrapping and found it to be a problem a few times when i was trying to print out the documents for reading.
I assume many will find on the plane that they have printed out things that have been truncated so i wanted to have something that had a good printing format.

if you want straight text with line breaks that is fine.

d


Jeff Heflin wrote:

> I am not sure I am comfortable with including the explainability
> requirement in this document. Although I can clearly see the usefulness
> of explainability, I don't think it is absolutely necessary in OWL. In
> fact, I think it would be better suited for the Proof layer of the
> Semantic Web (whenever the W3C gets around to defining it). Furthermore,
> I don't see how it directly impacts language design (as opposed to
> system design). In your possible approach section, the only thing that
> seems language related is the ability to tag information with its souce.
> What other language features would be necessary? I could be wrong, but I
> would think that any language which has a proof theory is inherently
> explainable (although systems that implement the language may or may not
> support explainability). Thus, I believe explainability is not a
> language requirement, but may instead be a requirement for specific
> applications.  However, I'd like to get input from the rest of the group
> in order to make a decision on this.
>
> Second, I don't want to have our candidate requirements elevated to that
> same status as those that had achieved a reasonable consensus. However,
> I would be willing to include them in an appendix perhaps called "Other
> desirable features". If Explainability does not make the cut for actual
> requirement, then we can put it there as well.
>
> Finally, I intentionally kept the document in text format in order to
> make it easy for anyone to read and edit. I also wanted something that
> could be easily converted to whatever format the combined use cases
> document will be in. As I understand, many at the W3C object to
> exchanging documents in a proprietary format (e.g., Word). Furthermore,
> the HTML generated by Word is awful (just look at the source sometime,
> there are all sorts of junk in there). I understand your concern about
> reading extra long lines, but most mail readers, text editors, and word
> processors can be configured to word wrap when displaying such
> documents. Let's keep the document as ASCII text until a format for the
> combined document is decided on.
>
> Jeff
>
> Deborah McGuinness wrote:
> >
> > I have made another update (building on top of my previous update).
> > I did a few things:
> >
> > 1 - wrote up R18 - explainability
> > 2 - added our previous definitions for the topics that we had discussed but not come to consensus on
> > 3- added a section populated with only 2 topics for requirements that emerged from other groups.  I took the topics that emerged from Guus' presentation yesterday and put down default information and part/whole information
> > 4- i put the document in word (because of the problem having to scroll left to right to read the document in its no carriage return format) and then also dumped it in html form for those who dont like word.
> >
> > I attach to two forms of the document here but I also put them both up on the web at:
> > http://www.ksl.Stanford.EDU/people/dlm/owl/
> >
> > I propose that this is the new baseline.
> > If anyone wants to write up a case for any of the topics that just have a name and a description, please do so asap.
> >
> > thanks,
> > Deborah
> >

--
 Deborah L. McGuinness
 Knowledge Systems Laboratory
 Gates Computer Science Building, 2A Room 241
 Stanford University, Stanford, CA 94305-9020
 email: dlm@ksl.stanford.edu
 URL: http://ksl.stanford.edu/people/dlm/index.html
 (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801 705 0941

Received on Friday, 4 January 2002 19:25:36 UTC