Re: REQDOC: NEED INPUT!

The slides that I sent out jan 16 include the updates from the breakout
session that I chaired.
If useful, i can take that and turn it into text.

also, to dan, i suggest that the presentation that jeff gave link to the
updated presentation that I sent.
what i sent is just an update to the presentation jeff gave from our group.

deborah

Jeff Heflin wrote:

> Hello,
>
> On Jan. 17, I asked for the chairs of the use case groups to provide
> input for the Requirements Document. I have still not received any. Of
> course, my original request said by "Wed. Jan 24," and since Wednesday
> was actually the 23rd this may have led to some confusion. Hopefully, no
> one interpreted it as meaning "some later year where Jan. 24 falls on a
> Wednesday." ;-)
>
> Anyway, I'd like to reiterate my request. If we have to, we'll simply
> use the read-ahead documents for the face-to-face as our input, but then
> we risk losing valuable information and insights that came out of the
> breakout sessions at the face-to-face. So please, try to get us this
> input by the end of the day. If you have nothing to add to the original
> use case documents, then let us know and we'll begin from there. Thank
> you for your cooperation.
>
> Jeff Heflin
>
> p.s. I've attached the original message below...
>
> --------------------------------------------------------------------------
>
> Hello everyone,
>
> It was a pleasure meeting many of you in New Jersey this week. We are
> preparing to edit the requirements document and need your input. If you
> were the chair of one of the breakout sessions on use cases please send
> us information on the following items produced by your session:
>
> Detailed representative use cases (about one page each)
> Detailed design goals, if any (about one page each)
> Requirements (short paragraphs, also mention which use case or design
> goal motivated the requirements)
>
> Please collect this in ASCII text format and post it to the mailing list
> with a REQDOC: prefix by Wed. Jan 24. Of course, you are welcome to
> solicit input from members of the original use case subgroup, but we
> would prefer if each group only posted a single message. If you are
> unable to meet this timeframe, please appoint someone from your use case
> group to perform this task. If my memory serves me correctly, the chairs
> of the use case breakout sessions were:
>
> Content Interoperablity - Mike Dean or Leo Obrst
> Collection Management - Guus Schreiber
> Web Services - Stefan Decker
> General Requirements - Deborah McGuinness
>
> To remind you of the use cases, design goals, and requirements, I've
> attached Jim's original summary of the product of the four breakout
> sessions. Note that I've sorted the requirements by the initial grade
> given by playing "Dan's game." Please send the paragraph for every
> requirement regardless of the grade assigned. We plan to provide things
> that some people see as requirements but were rejected by the group in a
> separate section, and at any rate having them there allows for us to
> still discuss and consider them.
>
> Thank you!
>
> Sincerely,
> Jeff, Jonathan, and Raphael
>
> ---------------------------------------------------------------------
>
> USE CASES:
> - web site mgt
> - Homogenous collection
> - doc about an object/artifact/design
>
> - Travel planning
> - Portal from multiple sources
>
> - Ubiq. Computing (small devices)
>
> DESIGN GOALS:
> - Shared Ontologies
> - Ontology Extension
> - Ontology evolution
> - Detect Inconsistency
> - Ontology Interoperability
> - Scalability
> - Ease of Use
> - XML syntax
> - Expressiveness
> - Internationalization
>
> REQUIREMENTS:
> A Annotation/tagging of ontologies (some particular properties)
> A Ontology namespaces/inter-ontology reference
> A ability to state uniq. names
> A character set support
> A lexical representation (internationalization)
> A ontology management language features (versioning)
> A unambiguous term referencing using URIs
> A uniqueness of unicode strings
> B Define range contraints on data types
> B Ontology mapping relations (equivalento)
> B ability to state closed worlds
> B commitment to  ontologies
> B ontology partitioning
> B solution to "tagging/grouping" problem
> B- Class as instance
> B- Relational Types
> B- records (complex datatypes)
> C capability (chaining of properties, transitivity)
> C effective decision procedure
> C layered approach
> C- commitment to portions of ontologies
> X ability to integrate signatures
> X bit efficient encoding
> X defaults
> X multicultural mechanism (view)
> X support for speech acts
> X unique name assumption
> - (procedural attachment)
> - Definitional constraints of conjunctive type
> - arithmetic primitives
> - pre and post conditions
> - support for expressing work flow
> - support for variables
>
> OPEN ISSUES:
> - defaults appear to be needed, but difficult or impossible
> - presentation syntax
> - explainability

--
 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 Thursday, 24 January 2002 12:34:39 UTC