RE: WebOnt Requirements - Summary

Straw poll (support S/against A/undecided U) + comments inline below.
R1  - S
R2  - S
R3  - S
R4  - S
R5  - S
R6  - S
R7  - S
R8  - U
R9  - U
R10 - S
R11 - S
R12 - S
R13 - S
R14 - S

Ned M. Smith
Intel Architecture Labs          Phone: 503.264.2692
2111 N.E. 25th Ave               Fax: 503.264.6225
Hillsoboro OR. 97124            mailto:ned.smith@intel.com


> -----Original Message-----
> From: Jeff Heflin [mailto:heflin@cse.lehigh.edu]
> Sent: Tuesday, December 11, 2001 12:40 PM
> To: 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: Jim Hendler; www-archive@w3.org
> Subject: WebOnt Requirements - Summary
> 
> 
> We've had a lot of discussion over the last 24 hours, so I thought it
> would be useful to try to summarize where we stand. Be warned 
> that this
> message is somewhat lengthy.
> 
> One issue that has come up is whether we should be considering only
> requirements for a certain "layer" of the Semantic Web. I believe that
> it is useful if we identify all requirements for an ideal semantic web
> language. We can then divide these into which are more appropriate for
> RDF, or for a yet to be named Proof layer.
> 
> I have tried to gather all of the proposed requirements and 
> issues from
> our discussion into a single list, which is at the bottom of this
> message. I've numbered each requirement and attempted to 
> provide a short
> description of it. Additionally, I've included open issues for many
> requirements, and assigned letters to these issues. If you'd like to
> propose a change to a requirement or add an issue, please 
> refer to it by
> number (e.g., R6). If you'd like to respond to or comment on an issue,
> please refer to it by number and name (e.g., R2.b). I'll try 
> to maintain
> this list as discussion continues. I don't expect that we'll solve all
> these issues anytime soon, but I think at least having them gathered
> together will help us focus on the job at hand. If you add a 
> requirement
> or issue, assign it the next number or letter.
> 
> I request that we have a straw poll on the requirements that 
> we have so
> far. For each requirement, I'd like to know whether you 
> support it (even
> though it may be out of scope), are against it, or are 
> undecided. It may
> be useful to provide a short explanation for your negative 
> votes. Also,
> feel free to state whether or not you think each requirement is in the
> scope of the WebOnt effort. I want to eventually produce two 
> lists: one
> a list of requirements we think are important for WebOnt and a list of
> requirements we think are important but are out of scope of 
> this effort.
> Then we can focus on writing up those requirements that are important
> and in scope.
> 
> Thanks!
> 
> Jeff
> 
> --------------------------------------------------------------
> ---------
> 
> WebOnt Candidate Requirements
> -------------------------------
> 
> R1. Shared ontologies
> Ontologies are publicly available and different data sources 
> can commit
> to the same ontology for shared meaning.
> 
> R2. Ontology extension
> Ontologies can be extended by other ontologies in order to provide
> additional definitions.
> Issues:
> a) Import all axioms wholesale into new ontology?
> b) Include definitions but don't allow them to be redefined or
> restricted?
> c) Simply reuse names but not definitions?
Issues seem to be struggling over concepts like inheritance, polymorphism
and template classes. Are they mutually exclusive? All seem valuable. But in
the interest of 80/20 simplification b) appears to align with inheritance -
which is already part of DAML+OIL. 

> 
> R3. Ontology evolution
> Ontologies can be changed over time and data sources can specify which
> version of the ontology they commit to.
> Issues:
> a) How does this differ from ontology extension (R2)? In R2, the
> original ontology is unchanged.
Versioning features should (IMO) make it easy to apply revision control
logic to scalar data. It seems reasonable to think of ontologies as scalar
data in the sense that the version (number?) permeates all sub-elements. But
the possible consequences of improperly managed versioning are profound.
Consider a temperature sensor ontology that defines a temperature tolerance
range between -10c and 100c. And an ontology change resulted in the sensor
being clasified as a plasma temperature sensor then the tolerance range
might mistakenly be interpreted as kelvin (in which case -10k to 100k is
incompatible with device capabilities).

Versioning is as fundamental as naming. URI-->URV where the namespace is
fixed in time as well as in space???
> 
> R4. Ontology interoperability
> Different ontologies may model the same concepts in different 
> ways. The
> language should provide primitives for relating different
> representations, thus allowing data to be converted to different
> ontologies, and enabling a "web of ontologies."
> 
> R5. Inconsistency
> Different ontologies may be contradictory, or different data 
> sources may
> be contradictory. It should be possible to detect inconsistencies. 
> Issues:
> a) Since inconsistency will probably be inevitable on the 
> Web, we should
> probably also provide means for continuing reasoning in the face of
> inconsistency.
> 
> R6. Scalability
> The language should be able to be used with large ontologies and large
> data sets.
I would like to hear the groups views on how ontology would be used to
describe the multi-faceted approaches for representing large data sets ala
indexing, distribution, caching etc. 

> 
> R7. Ease of Use
> The language should provide a low-learning barrier and have clear
> concepts and meaning. The concepts should be independent from syntax.
Who is the target audience?

> 
> 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?
> 
> 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?
I interpret the semantic web to have peer-peer semantics. The browser based
web (based on html/http) appears to be the origin of the "all or nothing"
and "viewable" semantics. I'm not sure "viewable" and "web pages" are the
right metaphores going forward? The metaphore I've been using is that an
ontology describes a structure that contains both data and meta-data, it is
traversable and it can reveal new information at every traversal. It is
reasonable to expect arbitrary sub-structures will be off-limits to some set
of probers, for some set of operations, for some period of time. (If I'm
misunderstanding ontology or misusing the metaphore someone please clarify -
this is potentially a fundamental clarification).

DAML-S supports the notion of a pre-condition which arguably is the right
place to apply access control semantics. DAML-S is a services ontology which
would be expressed using WOWG-ORL/WOL. I assume the DAML-S ontology would be
public domain and readily accessible. However, proprietary extensions to a
DAML-S ontology might redefine precondition, which implies introspection
might also be limited. There is an element of circularity that is suspect. A
ORL is used to describe an ontology that defines a semantic (precondition)
that is needed to prevent unauthorized traversal of the ontology that
originally defines the semantic.
 
> b) Some have argued that security is essential and should be seen as a
> vertical slice in the "layer cake"
> 
> R10. XML syntax
> The language should have an XML serialization.
> Issues:
> a) Must it also build on RDF?
> 
> R11. Internationalization
> The language should support ontologies in multiple languages.
> Issues:
> a) Is this already covered by interoperability (R4)?
> b) Character set issues are already handled by XML
> 
> R12. Ontology-based search
> Ability to locate information using the ontology to structure queries?
> Or is this something else?
> Issues:
> a) Is this searching for content (information retrieval) or for valid
> inferences (logical deduction)?
Is discovery considered one or the other?
> 
> 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?
I would like to understand how an agent might know how not to get confused
trying to learn the logical structure of say the network of post offices
when the ontology describing the network may be full of indexed, replicated
and distributed repositories whose physical structure (also represented by
ontology) is mostly superfluous to what is wanted.
> b) Is this maybe the need for a standard query language?
> 
> 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)?
> 
> R15. Proof checking
> Proofs can be described in the language and will be checkable.
> 
> 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.
>

Received on Tuesday, 11 December 2001 20:25:43 UTC