- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Tue, 11 Dec 2001 23:25:49 -0500
- To: Jeff Heflin <heflin@cse.lehigh.edu>, herman.ter.horst@philips.com, dlm@ksl.stanford.edu, phayes@ai.uwf.edu, jos.deroo.jd@belgium.agfa.com, jjc@hplb.hpl.hp.com, ned.smith@intel.com
- Cc: www-archive@w3.org
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