Re: WebOnt Requirements - Summary

Jeff/Deb/all -
  A couple of chair comments:

  I think you're making a good start on this - in talking w/W3C folks 
it is clear that an outcome we'd like to see from this requirements 
effort is to be able to say what these reqs say to the language 
design - i.e. what will need to go into the language that RDFS won't 
do or cover.  I think this will mean that from this starting place 
this group will need to drill down and work on how these things 
really impact the language (example - versioning may require some 
specific keywords be in the language ala Jeff's papers on the 
subject; ontology interoperability may require something more that 
"daml:equivalentTo" etc.

  Also while I do get to be the final arbiter w/respect to scope 
(according to W3C rules, that is just about the only thing the chair 
has any say over!) I'm willing to be convinced that most things that 
aren't explicitely forbidden by the charter would be allowable, 
although if we stray too far from the charter I suspect the 
coordination group will let us know.  Looking over what you've all 
been doing, I think most of this is in scope, a few things tend 
towards gray areas  - comments inline below:

>
>WebOnt Candidate Requirements
>-------------------------------
>
>R1. Shared ontologies
>R2. Ontology extension
>R3. Ontology evolution
>R4. Ontology interoperability
>R5. Inconsistency
>R6. Scalability
>R7. Ease of Use

No problems with any of these w/respect to scope

>
>R8. Data persistence
>The Web is constantly changing, so it would be useful to know the
>lifetime of information. This will be useful for agents to know when
>they must refresh their knowledge bases.
>Issues:
>a) Should this be specified for a fact in a data source, or for a
>property in an ontology?

I'd never thought of that one before, but the notion of being able to 
time tag data is a very interesting one.  My only worry is that if it 
strays from langauge construct to "temporal reasoner" it goes out of 
scope -- i.e. a mechanism allowing facts to be tagged (in general or 
for time) is good, a mechanism for specific temporal content and how 
to reason thereon probably strays too far.

>
>R9. Security
>Ability to specify who can view and modify information. Have ontologies
>that can specify access control information.
>Issues:
>a) Web typically doesn't allow update (except via file update) and
>viewing web pages is typically all or nothing, so how is this relevant?
>b) Some have argued that security is essential and should be seen as a
>vertical slice in the "layer cake"

I think the notion of ontologies that can specify access control info 
is out of scope (i.e. it is content specific) -- i.e. stating a 
requirement that the language that is expressive enough to allow this 
is fine, having the language contain specific security content is 
probably out of scope.  I tend to agree in general that security must 
be built in to the lowest layers, but frankly am not sure how that 
plays out against a language definition like ours

>R10. XML syntax
>The language should have an XML serialization.
>Issues:
>a) Must it also build on RDF?

R10 is in the charter - so I think it is a definite req (both to have 
XML syntax and to be RDF-based, although RDF-based is loosely defined)

>
>R11. Internationalization

I think this is out of scope unless very focused on ontology-specific 
issues of internationalization - W3C has other folks 
w/internationalization as a specific focus and we don't want to stray 
into their area.  However, if there are ontology specific issues and 
the group wants to address them, I see that as in scope (example, one 
word or concept in a natural language might correspond to a set of 
content in another - i.e. the verb "stab" in English is expressed as 
"give wounds with a knife" in Spanish - one wouldn't be able to use 
daml:equivalentTo to map one to the other) similar things would come 
up outside the context of internationalization however (example, my 
4-wheeled vehicle maps to either your car or truck, but not to all 
your transport-devices) and might be better addressed in that context 
(perhaps with a pointer to internationalization in the discussion)


>R12. Ontology-based search

Now that I undrstand ontology-based search to be different than 
"search engine/IR" level stuff I think it is in scope, but it will 
need to be defined carefully as I think many of us were/are confused 
as to what is entailed (language-wise) by the content

>
>R13. Ontology querying
>Ability to ask questions about the logical structure of the ontology? Or
>is this something else?
>Issues:
>a) Are R12 and R13 the same requirement? May R12 is information
>retrieval and R13 is question answering?
>b) Is this maybe the need for a standard query language?

This is likely to be out of scope (because rules/query are linked in 
the list of things we were specifically asked not to do).  Honed down 
to a what is entailed by the ontology (i.e.is there a particular 
inheritance model where something is in multiple classes) it would 
come into scope.

>
>R14. Expressiveness
>What can be expressed in the language and what reasoning capabilities
>should be expected in systems that fully implement it.
>Issues:
>a) What is the right balance between expressiveness and scalability
>(R6)?

Charter has a list that implies we're not going for high expressivity 
but also allows some leeway - definitely we want maximal expressivity 
that doesn't violate the stuff above - particularly the first 7 or so 
(that's the tension)

>
>R15. Proof checking
>Proofs can be described in the language and will be checkable.

I think this would be out of scope, except as a use case (i.e. 
language can be expressive enough to define proofs)

>
>R16. Trust
>How to determine which information is reliable and/or believable. Must
>be able to know the sources of information and to express what
>supporting information is needed to believe something.

I think that trust per se is borderline at best, However I think 
this, and maybe several of these other requirements, suggest that the 
language will need a means of tagging triples - which is an 
intriquing idea and one that D+O never addressed (and we may or may 
not achieve consensus on - definitely makes the pure triple model 
problematic)

Anyway, sorry for going on so long - very nice start, and I look 
forward to seeing this drill down towards language needs
  -JH


--

Received on Tuesday, 11 December 2001 23:29:44 UTC