Re: WOLREQS: Draft requirements document

Thanks for the edits, Deborah. Does anyone have any objections to
Deborah's edits and/or additions? If not, then this will become our new
baseline. If you have other corrections or additions, please send them
to the group soon. We must freeze this document by Monday, Jan. 7.
Therefore, I ask that you send any suggestions to the group by noon
tomorrow, so that we may have time to discuss them and incorporate them.

Jeff

Deborah McGuinness wrote:
> 
> thanks for the good work.
> I did an editing pass and also included ontology-based search in it.
> I only added information except for the DAML SUPPORT section of R7 where i did  a little editing and rewrote a couple of sentences.
> 
> deborah
> 
> ===================
> WebOnt General Requirements
> 
> This document was prepared by the General Requirements Subgroup, which consists of the following individuals:
> 
> Jeff Heflin (co-chair)          heflin@cse.lehigh.edu
> Deborah McGuinness (co-chair)   dlm@ksl.stanford.edu
> Jeremy Carroll                  jeremy_carroll@hp.com
> Dan Connolly                    connolly@w3.org
> Jos De Roo                      jos.deroo.jd@belgium.agfa.com
> Pat Hayes                       phayes@ai.uwf.edu
> Ned Smith                       ned.smith@intel.com
> Herman ter Horst                herman.ter.horst@philips.com
> 
> PURPOSE:
> The purpose of this document is to identify requirements that are too general to result from any single use case area, cut across all use cases areas, or are not directly related to the existing use cases, but nonetheless important.
> 
> REQUIREMENTS:
> The following requirements are recommended by the group.
> 
> R1. Shared Ontologies
> 
> Ontologies are publicly available and different data sources can commit to the same ontology for shared meaning.
> 
> SUPPORTED TASKS:
> Any use case in which distributed data sources use shared terminology.
> 
> JUSTIFICATION:
> Interoperability requires agreements on the definitions of terms. Ontologies can provide standard sets of terms and formal definitions of those terms. Data sources that commit to the same ontology explicitly agree to use the same terms with the same meanings.
> 
> POSSIBLE APPROACH:
> Although DTDs and XML Schemas can be used to define the syntax of a language, they cannot provide machine-readable semantic definitions for the terms of the language. A web ontology language needs:
> 
> 1) syntax for defining ontologies
> 2) syntax for WebOnt documents to commit to one or more ontologies
> 3) syntax for ordering (or otherwise specifying selection criteria) if 2 or more committed
> ontologies contain the same term
> 
> DAML SUPPORT:
> DAML+OIL provides an daml:Ontology element and a number of primitives for defining classes and properties. It uses XML namespaces to identify which set of terms it is using and a daml:imports statement can be used in data documents to effectively commit to the definitions of specific ontologies.
> 
> R2. Ontology Extension
> 
> Ontologies can be extended by other ontologies in order to provide additional definitions.
> 
> SUPPORTED TASKS:
> Any use case in which the providers of data are decentralized.
> 
> JUSTIFICATION:
> Often, shared ontologies are not sufficient. An organization may find that an existing ontology provides 90% of what they need, but the remaining 10% is critical. In such cases, the organization should not have to create a new ontology from scratch, but instead be able to create an ontology which extends an existing ontology and adds any desired terms and definitions.
> 
> POSSIBLE APPROACH:
> Although RDF uses XML namespaces to include names from other schemas, there is no discussion of how this relates to the definitions of the names. For example, if definitions for a single name occur in three different schemas, but a document only includes the namespace for one, then it is unclear whether the definition intended by the document is the conjunction of the three schemas, or only the schema which the namespace includes. To explicitly express which definitions are intended, the web ontology language needs syntax for expressing ontology extension.
> 
> DAML SUPPORT:
> daml:imports allows an ontology to include the definitions from another ontology.
> 
> OPEN ISSUES:
> An important issue is determining the precise semantics of the extension mechanism. Is it equivalent to including the extended ontology in the new document? Does it allow definitions to be refined or restricted?  Also, what happens if the extensions generate incoherent term descriptions?
> 
> R3. Ontology Evolution
> Ontologies can be changed over time and data sources can specify which version of the ontology they commit to.
> 
> SUPPORTED TASKS:
> Any use case in which the ontology could potentially change, and in particular those in which the owner of the ontology is different from the data providers.
> 
> JUSTIFICATION:
> Since the web is constantly growing and changing, we must expect ontologies to change as well. Ontologies may need to change because there were errors in prior versions, a new way of modeling the domain is preferred, or reality has changed (e.g., the addition of new technology). A web ontology language must be able to accommodate ontology revision. Note that ontology evolution is different from R2, because R2 does not change the original ontology. An important issue of revision is whether or not documents that commit to one version of an ontology are compatible with those that commit to another. Both compatible and incompatible revisions should be allowed, but it should be possible to distinguish between the two. Note that it is possible for a revision to change the intended meaning of a term without changing any axioms, thus determining backwards-compatibility requires more than a simple comparison of axioms.
> 
> POSSIBLE APPROACH:
> Allowing ontologies to change arbitrarily can have undesirable side effects in documents that committed to prior versions of the ontology. Since these documents are distributed and owned by different parties, it is impossible to coordinate an update to the ontology with updates to all documents that depend on it. One possible solution is:
> 
> 1) Each revision of an ontology is a separate document that has a unique identity in web space (its own URL).
> 
> 2) A construct for expressing that an ontology revises a prior version
> 
> 3) A construct for expressing that a revision is backwards-compatible with one or more prior versions
> 
> 4) A construct for expressing that certain terms are deprecated, and thus maintained in a revision simply for compatibility with earlier versions. This allows terms to be phased out while retaining backwards-compatibility.
> 
> 5) A way of committing to a specific version number of an ontology or the latest version of that ontology.
> 
> DAML SUPPORT:
> In DAML+OIL, each ontology has its own URL. Each ontology has a daml:versionInfo element that contains a string giving information about the version it represents. However, there is no specified structure for this string, and thus it is of little use for automated software that wishes to determine which ontologies are prior versions of other ontologies. DAML+OIL does not include features for specifying backwards-compatibility or deprecation.
> 
> 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." However, this requirement must be balanced with the need for scalability (R6).
> 
> SUPPORTED TASKS:
> Any use case in which data from different providers with different terminologies must be integrated.
> 
> JUSTIFICATION:
> Although shared ontologies (R1) and ontology extension (R2) allow a certain degree of interoperability between different organizations and domains, there are often cases where there are multiple ways to model the same information. This may be due to differences in the perspectives of different organizations, different professions, different nationalities, etc. In order for machines to be able to integrate information that commits to heterogeneous ontologies, there need to be primitives that allow ontologies to map terms to equivalents in other ontologies.
> 
> POSSIBLE APPROACH:
> There are many ways that different ontologies can model the same concepts, resulting in different types of heterogeneity. One approach is to have the expressivity of first order logic, which can be used to define articulation axioms and resolve most of the kinds of differences. However, this solution is not in line with the scalability requirement. Below is a list of language features that can be used to map heterogeneous ontologies; the web ontology language should include some (but probably not all of these).
> 
> 1) subclass/superclass relations
> 2) inverse relationships
> 3) equivalence of concepts (for classes, properties, and individuals)
> 4) logical constructs (implication, conjunction, disjunction)
> 5) arithmetic functions
> 6) aggregation (e.g., like SQL GROUP BY)
> 7) string manipulation
> 8) procedural attachments (executable code, possibly Java, that can be used to define arbitrarily complex mappings)
> 
> Another approach may not to be to include the expressivity of first order logic but instead reduce the expressive power of the language in which the articulation or mapping axioms are expressed.  For example, a limited language might be allowed to state that term A in Ontology 1 is equivalent to term B in Ontology 2 with the following additional restrictions (where those restrictions are not in a language that is as expressive as FOL).
> 
> DAML SUPPORT:
> DAML+OIL contains the rdfs:subClassOf and rdfs:subPropertyOf relations for defining taxonomic relations of classes and properties, respectively. It also has the daml:equivalentTo family of properties (daml:sameClassAs, daml:samePropertyAs, and daml:sameIndividualAs) for expressing equivalence of classes, properties, and individuals. There is a daml:inverseOf property for defining inverse relationships. Finally, the description logic primitives allow for mappings similar to some of the logical constructs. However, DAML+OIL does not have features for expressing implication, arithmetic functions, aggregation, string manipulation, or procedural attachments.
> 
> R5. Detect Inconsistency
> Different ontologies or data sources may be contradictory. It should be possible to detect inconsistencies.
> 
> SUPPORTED TASKS:
> Any use cases in which decentralization of data and lack of controlling authority can lead to conflicts in the data.
> Any ontology evolution task that may result in incoherent descriptions (possibly by extending an ontology in a way that generated an overconstrained term).
> 
> JUSTIFICATION:
> The Web is decentralized, allowing any one to say anything. As a result, different viewpoints may be contradictory, or even false information may be provided. In order to prevent agents from combining incompatible data or from taking consistent data and evolving it into an inconsistent state, it is important that inconsistencies can be detected automatically.
> 
> POSSIBLE APPROACH:
> First the language must be able to express inconsistent situations. This could be done with a negation operator, disjointness of sets, cardinality restrictions, etc.
> Second, a reasoning component must be able to detect inconsistencies.  Third, some reporting mechanism must be made available to report inconsistencies possibly along with an explanation of how the inconsistency was generated.
> 
> DAML SUPPORT:
> DAML+OIL can express disjoint classes (using daml:disjointWith), cardinality restrictions (with daml:cardinality, daml:minCardinality, and daml:,maxCardinality), and complements (with daml:complementOf). Using a description logic reasoner, inconsistencies within an ontology, between a set of ontologies, and between ontologies and data sources can be detected.
> 
> R6. Scalability
> The language should be able to be used with large ontologies and large data sets. However, the language must balance this requirement with Expressiveness(R14).
> 
> SUPPORTED TASKS:
> Any use case that uses large ontologies or large data sets.
> 
> JUSTIFICATION:
> There are over one billion pages on the Web, and the potential application of the Semantic Web to embedded devices and agents poses even larger amounts of information that must be handled. The web ontology language must support systems that can scale to these sizes.
> 
> POSSIBLE APPROACH:
> Many expressive languages are intractable, resulting in them not being scalable. One solution is to restrict the language to features that have efficient algorithms for reasoning. Two candidates for limited reasoning are description logics and datalog.
> 
> DAML SUPPORT:
> DAML+OIL is based on  a description logic language for which tractable reasoners may be built.
> 
> 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.
> 
> SUPPORTED TASKS:
> Markup and querying of semantic web documents by users, either directly or indirectly.
> 
> JUSTIFICATION:
> Although ideally most users will be isolated from the language by front end tools, the basic philosophy of the language must be natural and easy to learn. Furthermore, early adopters, tool developers, and power users may work directly with the syntax, meaning human readable (and writable) syntax is desirable.
> 
> POSSIBLE APPROACH:
> Where possible, use concepts and idioms that are familiar to ordinary software engineers and computer scientists. For example, relate ideas to object oriented and or relational databases.  One or more presentation syntaxes could be provided that are natural to users.
> 
> DAML SUPPORT:
> DAML+OIL's classes are equivalent to classes in object-oriented terminology. DAML+OIL also incorporates features from frame-based systems and description logics.
> DAML+OIL?s syntax however has not retained features that have made some of its foundational components such as object-oriented systems and frame systems and more widely used description logics more usable.   As the language was generated to be compatible with the RDF framework, arguably some of the useful syntax features present in other languages were not preserved.
> 
> R10. XML syntax
> The language should have an XML serialization.
> 
> SUPPORTED TASKS:
> Exchange of ontologies and data in a standard format.
> 
> JUSTIFICATION:
> XML has become widely accepted by industry and numerous tools for processing XML have been developed. If the web ontology language has an XML syntax, then these tools can be extended an reused.
> 
> POSSIBLE APPROACH:
> Provide an XML syntax for the language.
> 
> DAML SUPPORT:
> DAML+OIL extends RDF and RDF-Schema, which in turn have XML serializations.
> 
> OPEN ISSUES:
> There is lack of consensus as to whether the language should also build on RDF and RDF Schema. The arguments for building on RDF are that it is a W3C Recommendation and there exists software for parsing it. Arguments against RDF include that it does not have the widespread acceptance of XML, and trying to fit DAML+OIL into it has occasionally resulted in awkward language constructs.
> 
> R12 Ontology-based search
> Conceptual search or semantic search - search exploiting the meaning of terms instead of just the syntax of the search terms.
> 
> SUPPORTED TASKS:
> Any ?find? capability that attempts to exploit term meaning including synonyms, subclass/superclass relationships, relationships between terms, or parametric search.
> 
> JUSTIFICATION:
> It is widely recognized that simple statistical information retrieval techniques for search have limitations.  If for example, a user is looking for a car when a web site contains only the word automobile, then no matches will be found even though information exists that would be relevant to the user?s query.  Market research shows that search is one of the most important functionalities on web sites ([1] ) and also that sophisticated search is imperative for ecommerce sites ([2]).  Also, as objects become complicated and compositional, it becomes more important to be able to search for relationships between terms (such as the ?capital of France?  and not just retrieve all documents about France) or ?red cashmere sweater with a price under 150 dollars?.   The latter is typically called parametric search where parameters on the class sweater are restricted.  Parametic search, relational search, and standard
> conceptual search all rely on term meaning and term composition of search terms and also on the meaning of the terms in the document to be retrieved.
> 
> POSSIBLE APPROACH:
> Use background ontologies to provide:
> 1) query expansion using synonyms and subclasses (and possibly more) from the background ontology
> 2) understanding of  term relationships - capitals of countries are cities that are located geographically inside the country?.
> 3) Identify parameters appropriate to classes and their value restrictions
> 
> DAML SUPPORT:
> Background ontologies can be expressed in DAML+OIL.  Also, queries can be formed from DAML expressions.
> 
> R14. Expressiveness
> The language should be as expressive as possible, given a balance with requirement R6, Scalability. Expressivity determines what can be said in the language, and thus determines its inferential power and what reasoning capabilities should be expected in systems that fully implement it.
> 
> SUPPORTED TASKS:
> Any use case that requires the representation of diverse knowledge.
> 
> JUSTIFICATION:
> The degree of semantics that can be expressed by a language depend on the primitives that it provides. An expressive language contains a rich set of primitives that allow a wide variety of knowledge to be formalized. A language with too little expressivity will provide too few reasoning opportunities to be of much use and may not provide any contribution over existing languages.
> 
> POSSIBLE APPROACH:
> One possible approach is to base the language on first order logic, but this conflicts with R6, Scalability. Therefore, more restricted, yet more scalable alternatives should be considered. Two such alternatives are description logics and datalog.
> 
> DAML SUPPORT:
> DAML+OIL is based on an description logic that has had its constructors chosen to maintain tractability of reasoning.
> 
> Bibliography:
> [1] Laura Koetzle, Paul Hagen, Hillary Drohan, and Moira Dorsey.  "Smarter Sales
> of Complex Goods".   The Forrester Report. Cambridge, Mass. September 2001.
> 
> [2] Paul Hagen, David Weisman, Harley Manning, and Randy Souza.  "Guided Search
> for eCommerce ".  The Forrester Report.  Cambridge, Mass. January, 1999.
> ====================
> 
> Jeff Heflin wrote:
> 
> > Hello everyone,
> >
> > I have attached the draft requirements document for our group. This
> > document includes all of the requirements that had received four or more
> > votes of support in our straw poll. I'd like you to read this document
> > and suggest changes. If any proposed changes are potentially
> > contentious, I'll ask that they be discussed by the group and then put
> > to vote. Note that following candidate requirements are currently
> > omitted:
> >
> > R8. Data Persistence
> > R9. Security
> > R11. Internationalization
> > R12. Ontology-based Search
> > R13. Ontology Querying
> > R15. Proof Checking
> > R16. Trust
> > R17. Tagging
> >
> > If you think one of these should be added, write it up in the same
> > format as the requirements in the attached document and state your case
> > to the group.
> >
> 
> > We need to freeze this document by Jan. 7, so that people can have time
> > to read it before the face-to-face meeting. Since many of us may be away
> > next week, we probably won't have much discussion then. If possible,
> > please read through the document and formulate your opinions. Feel free
> > to post suggestions, but don't expect much response. The following week
> > (Dec. 31 through Jan. 4) we will discuss any issues and make changes to
> > the document. Note, if you are unable to participate between now and
> > Jan. 4 and would feel uncomfortable with your name on a document that
> > that you didn't have a chance to give input on, please let know.
> >
> > Happy holidays,
> > Jeff
> >
> >   ------------------------------------------------------------------------
> > WebOnt General Requirements
> >
> > This document was prepared by the General Requirements Subgroup, which consists of the following individuals:
> >
> > Jeff Heflin (co-chair)          heflin@cse.lehigh.edu
> > Deborah McGuinness (co-chair)   dlm@ksl.stanford.edu
> > Jeremy Carroll                  jeremy_carroll@hp.com
> > Dan Connolly                    connolly@w3.org
> > Jos De Roo                      jos.deroo.jd@belgium.agfa.com
> > Pat Hayes                       phayes@ai.uwf.edu
> > Ned Smith                       ned.smith@intel.com
> > Herman ter Horst                herman.ter.horst@philips.com
> >
> > PURPOSE:
> > The purpose of this document is to identify requirements that are too general to result from any single use case area, cut across all use cases areas, or are not directly related to the existing use cases, but nonetheless important.
> >
> > REQUIREMENTS:
> > The following requirements are recommended by the group.
> >
> > R1. Shared Ontologies
> >
> > Ontologies are publicly available and different data sources can commit to the same ontology for shared meaning.
> >
> > SUPPORTED TASKS:
> > Any use case in which distributed data sources use shared terminology.
> >
> > JUSTIFICATION:
> > Interoperability requires agreements on the definitions of terms. Ontologies can provide standard sets of terms and formal definitions of those terms. Data sources that commit to the same ontology explicitly agree to use the same terms with the same meanings.
> >
> > POSSIBLE APPROACH:
> > Although DTDs and XML Schemas can be used to define the syntax of a language, they cannot provide machine-readable semantic definitions for the terms of the language. A web ontology language needs:
> >
> > 1) syntax for defining ontologies
> > 2) syntax for WebOnt documents to commit to one or more ontologies
> >
> > DAML SUPPORT:
> > DAML+OIL provides an daml:Ontology element and a number of primitives for defining classes and properties. It uses XML namespaces to identify which set of terms it is using and a daml:imports statement can be used in data documents to effectively commit to the definitions of specific ontologies.
> >
> > R2. Ontology Extension
> >
> > Ontologies can be extended by other ontologies in order to provide additional definitions.
> >
> > SUPPORTED TASKS:
> > Any use case in which the providers of data are decentralized.
> >
> > JUSTIFICATION:
> > Often, shared ontologies are not sufficient. An organization may find that an existing ontology provides 90% of what they need, but the remaining 10% is critical. In such cases, the organization should not have to create a new ontology from scratch, but instead be able to create an ontology which extends an existing ontology and adds any desired terms and definitions.
> >
> > POSSIBLE APPROACH:
> > Although RDF uses XML namespaces to include names from other schemas, there is no discussion of how this relates to the definitions of the names. For example, if definitions for a single name occur in three different schemas, but a document only includes the namespace for one, then it is unclear whether the definition intended by the document is the conjunction of the three schemas, or only the schema which the namespace includes. To explicitly express which definitions are intended, the web ontology language needs syntax for expressing ontology extension.
> >
> > DAML SUPPORT:
> > daml:imports allows an ontology to include the definitions from another ontology.
> >
> > OPEN ISSUES:
> > An important issue is determining the precise semantics of the extension mechanism. Is it equivalent to including the extended ontology in the new document? Does it allow definitions to be refined or restricted?
> >
> > R3. Ontology Evolution
> > Ontologies can be changed over time and data sources can specify which version of the ontology they commit to.
> >
> > SUPPORTED TASKS:
> > Any use case in which the ontology could potentially change, and in particular those in which the owner of the ontology is different from the data providers.
> >
> > JUSTIFICATION:
> > Since the web is constantly growing and changing, we must expect ontologies to change as well. Ontologies may need to change because there were errors in prior versions, a new way of modeling the domain is preferred, or reality has changed (e.g., the addition of new technology). A web ontology language must be able to accommodate ontology revision. Note that ontology evolution is different from R2, because R2 does not change the original ontology. An important issue of revision is whether or not documents that commit to one version of an ontology are compatible with those that commit to another. Both compatible and incompatible revisions should be allowed, but it should be possible to distinguish between the two. Note that it is possible for a revision to change the intended meaning of a term without changing any axioms, thus determining backwards-compatibility requires more than a simple comparison of axioms.
> >
> > POSSIBLE APPROACH:
> > Allowing ontologies to change arbitrarily can have undesirable side effects in documents that committed to prior versions of the ontology. Since these documents are distributed and owned by different parties, it is impossible to coordinate an update to the ontology with updates to all documents that depend on it. One possible solution is:
> >
> > 1) Each revision of an ontology is a separate document that has a unique identity in web space (its own URL).
> >
> > 2) A construct for expressing that an ontology revises a prior version
> >
> > 3) A construct for expressing that a revision is backwards-compatible with one or more prior versions
> >
> > 4) A construct for expressing that certain terms are deprecated, and thus maintained in a revision simply for compatibility with earlier versions. This allows terms to be phased out while retaining backwards-compatibility.
> >
> > DAML SUPPORT:
> > In DAML+OIL, each ontology has its own URL. Each ontology has a daml:versionInfo element that contains a string giving information about the version it represents. However, there is no specified structure for this string, and thus it is of little use for automated software that wishes to determine which ontologies are prior versions of other ontologies. DAML+OIL does not include features for specifying backwards-compatibility or deprecation.
> >
> > 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." However, this requirement must be balanced with the need for scalability (R6).
> >
> > SUPPORTED TASKS:
> > Any use case in which data from different providers with different terminologies must be integrated.
> >
> > JUSTIFICATION:
> > Although shared ontologies (R1) and ontology extension (R2) allow a certain degree of interoperability between different organizations and domains, there are often cases where there are multiple ways to model the same information. This may be due to differences in the perspectives of different organizations, different professions, different nationalities, etc. In order for machines to be able to integrate information that commits to heterogeneous ontologies, there need to be primitives that allow ontologies to map terms to equivalents in other ontologies.
> >
> > POSSIBLE APPROACH:
> > There are many ways that different ontologies can model the same concepts, resulting in different types of heterogeneity. One approach is to have the expressivity of first order logic, which can be used to define articulation axioms and resolve most of the kinds of differences. However, this solution is not in line with the scalability requirement. Below is a list of language features that can be used to map heterogeneous ontologies; the web ontology language should include some (but probably not all of these).
> >
> > 1) subclass/superclass relations
> > 2) inverse relationships
> > 3) equivalence of concepts (for classes, properties, and individuals)
> > 4) logical constructs (implication, conjunction, disjunction)
> > 5) arithmetic functions
> > 6) aggregation (e.g., like SQL GROUP BY)
> > 7) string manipulation
> > 8) procedural attachments (executable code, possibly Java, that can be used to define arbitrarily complex mappings)
> >
> > DAML SUPPORT:
> > DAML+OIL contains the rdfs:subClassOf and rdfs:subPropertyOf relations for defining taxonomic relations of classes and properties, respectively. It also has the daml:equivalentTo family of properties (daml:sameClassAs, daml:samePropertyAs, and daml:sameIndividualAs) for expressing equivalence of classes, properties, and individuals. There is a daml:inverseOf property for defining inverse relationships. Finally, the description logic primitives allow for mappings similar to some of the logical constructs. However, DAML+OIL does not have features for expressing implication, arithmetic functions, aggregation, string manipulation, or procedural attachments.
> >
> > R5. Detect Inconsistency
> > Different ontologies or data sources may be contradictory. It should be possible to detect inconsistencies.
> >
> > SUPPORTED TASKS:
> > Any use cases in which decentralization of data and lack of controlling authority can lead to conflicts in the data.
> >
> > JUSTIFICATION:
> > The Web is decentralized, allowing any one to say anything. As a result, different viewpoints may be contradictory, or even false information may be provided. In order to prevent agents from combining incompatible data, it is important that inconsistencies can be detected automatically.
> >
> > POSSIBLE APPROACH:
> > First the language must be able to express inconsistent situations. This could be done with a negation operator, disjointness of sets, cardinality restrictions, etc.
> >
> > DAML SUPPORT:
> > DAML+OIL can express disjoint classes (using daml:disjointWith), cardinality restrictions (with daml:cardinality, daml:minCardinality, and daml:,maxCardinality), and complements (with daml:complementOf). Using a description logic reasoner, inconsistencies within an ontology, between a set of ontologies, and between ontologies and data sources can be detected.
> >
> > R6. Scalability
> > The language should be able to be used with large ontologies and large data sets. However, the language must balance this requirement with Expressiveness(R14).
> >
> > SUPPORTED TASKS:
> > Any use case that uses large ontologies or large data sets.
> >
> > JUSTIFICATION:
> > There are over one billion pages on the Web, and the potential application of the Semantic Web to embedded devices and agents poses even larger amounts of information that must be handled. The web ontology language must support systems that can scale to these sizes.
> >
> > POSSIBLE APPROACH:
> > Many expressive languages are intractable, resulting in them not being scalable. One solution is to restrict the language to features that have efficient algorithms for reasoning. Two candidates for limited reasoning are description logics and datalog.
> >
> > DAML SUPPORT:
> > DAML+OIL is based on description logics.
> >
> > 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.
> >
> > SUPPORTED TASKS:
> > Markup and querying of semantic web documents by users, either directly or indirectly.
> >
> > JUSTIFICATION:
> > Although ideally most users will be isolated from the language by front end tools, the basic philosophy of the language must be natural and easy to learn. Furthermore, early adopters, tool developers, and power users may work directly with the syntax, meaning human readable (and writable) syntax is desirable.
> >
> > POSSIBLE APPROACH:
> > Where possible, use concepts and idioms that are familiar to ordinary software engineers and computer scientists. For example, relate ideas to object oriented and or relational databases.
> >
> > DAML SUPPORT:
> > DAML+OIL's classes are equivalent to classes in object-oriented terminology. However, description logics are not widely known outside of the knowledge representation community. Furthermore, in order to fit description logic concepts into an RDF framework, DAML+OIL has some awkward syntax.
> >
> > R10. XML syntax
> > The language should have an XML serialization.
> >
> > SUPPORTED TASKS:
> > Exchange of ontologies and data in a standard format.
> >
> > JUSTIFICATION:
> > XML has become widely accepted by industry and numerous tools for processing XML have been developed. If the web ontology language has an XML syntax, then these tools can be extended an reused.
> >
> > POSSIBLE APPROACH:
> > Provide an XML syntax for the language.
> >
> > DAML SUPPORT:
> > DAML+OIL extends RDF and RDF-Schema, which in turn have XML serializations.
> >
> > OPEN ISSUES:
> > There is lack of consensus as to whether the language should also build on RDF and RDF Schema. The arguments for building on RDF are that it is a W3C Recommendation and there exists software for parsing it. Arguments against RDF include that it does not have the widespread acceptance of XML, and trying to fit DAML+OIL into it has occasionally resulted in awkward language constructs.
> >
> > R14. Expressiveness
> > The language should be as expressive as possible, given a balance with requirement R6, Scalability. Expressivity determines what can be said in the language, and thus determines its inferential power and what reasoning capabilities should be expected in systems that fully implement it.
> >
> > SUPPORTED TASKS:
> > Any use case that requires the representation of diverse knowledge.
> >
> > JUSTIFICATION:
> > The degree of semantics that can be expressed by a language depend on the primitives that it provides. An expressive language contains a rich set of primitives that allow a wide variety of knowledge to be formalized. A language with too little expressivity will provide too few reasoning opportunities to be of much use.
> >
> > POSSIBLE APPROACH:
> > One possible approach is to base the language on first order logic, but this conflicts with R6, Scalability. Therefore, more restricted, yet more scalable alternatives should be considered. Two such alternatives are description logics and datalog.
> >
> > DAML SUPPORT:
> > DAML+OIL is based on description logics.
> 
> --
>  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, 3 January 2002 09:21:23 UTC