Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.ksl.stanford.edu/people/dlm/webont/OWLFeatureSynopsisJuly8.htm below:

Feature Synopsis for OWL Lite and OWL

1. Motivation
2. Language Synopsis
   1. OWL Lite Synopsis
      1. OWL Lite RDF Schema Features Synopsis
      2. OWL Lite Equality and Inequality Synopsis
      3. OWL Lite Property Characteristics Synopsis
      4. OWL Lite Restricted Cardinality Synopsis
      5. OWL Lite Datatypes Synopsis
      6. OWL Lite Header Information Synopsis
   2. OWL Synopsis
      1. OWL Class Axioms Synopsis
      2. OWL Boolean Combinations of Class Expressions Synopsis
      3. OWL Arbitrary Cardinality Synopsis
      4. OWL Filler Information Synopsis
3. Language Description of OWL Lite
   1. OWL Lite RDF Schema Features Description
   2. OWL Lite Equality and Inequality Description
   3. OWL Lite Property Characteristics Description
   4. OWL Lite Restricted Cardinality Description
   5. OWL Lite Datatypes
   6. OWL Lite Header Information
4. Incremental Language Description of OWL
5. Summary
6. Status

The OWL Web Ontology Language is being designed by the W3C Web Ontology Working Group in order to provide a language that can be used for applications that need to understand the logical content of information instead of just understanding the human-readable presentation of content. The OWL language can be used to allow the explicit representation of term vocabularies and the relationships between entities in these vocabularies. In this way, the language goes beyond XML, RDF and RDF-S in allowing greater machine readable content on the web. The OWL language is a revision of the DAML+OIL web ontology language incorporating learnings from the design and application use of DAML+OIL.

The goal of this document is to provide a simple introduction to OWL. This document is meant to provide a language overview with a listing of language features along with simple descriptions and examples. The audience is expected to be people wishing to get a general understanding of the language capabilities. This document first describes a simpler version of the full OWL language which is referred to as OWL Lite and then describes OWL by addition to OWL Lite. A more complete language description will be provided in accompanying documents. For more information concerning the motivation and requirements for the OWL language, please see the Requirements for a Web Ontology Language document. For a more complete description of the language features in OWL and OWL Lite, please see the OWL reference description document. For a more complete description of the OWL Lite and OWL language semantics, please see the Formal Specification of the OWL Web Ontology Language Document.

This document begins by describing a subset of the entire language called OWL Lite. The goal of OWL Lite is to provide a language that is viewed by tool builders to be easy enough and useful enough to support. One expectation is that tools will facilitate the widespread adoption of OWL and thus OWL language designers should attempt to create a language that tool developers will flock to.
While it is widely appreciated that all of the features in languages such DAML+OIL are important to some users, it is also understood that a languages as expressive as DAML+OIL may be daunting to some groups who are trying to support a tool suite for the entire language. In order to provide a target that is approachable to a wider audience, a smaller language has been defined, now referred to as OWL Lite.

This smaller language attempts to capture many of the commonly used features of OWL and DAML+OIL. It also attempts to describe a useful language that provides more than RDFS with the goal of adding functionality that is important in order to support web applications. It also attempts to choose features that do not impose too many restrictions on toolbuilders who want to extend their support beyond this "Lite" language.

This document provides a feature synopsis for the full OWL language by including the feature synopsis for OWL Lite and then an incremental listing of the additions supported in OWL. The language description with examples for the full OWL Language is also done in an incremental manner over OWL Lite.

• Class
• Property
• subClassOf
• subPropertyOf
• domain
• range
• individual

• sameClassAs
• samePropertyAs
• sameIndividualAs
• differentIndividualFrom

• inverseOf
• transitive
• symmetric
• functional
• unambiguous (inverseFunctional)
• allValuesFrom (universal local range restrictions; previously toClass)
• someValuesFrom (existential local range restrictions; previously hasClass)

• minCardinality (restricted to 0 or 1)
• maxCardinality (restricted to 0 or 1)
• cardinality (restricted to 0 or 1)

Following the decisions of RDF Core.

• imports
• Dublin Core Metadata

• oneOf (enumerated classes)
• disjointWith
• sameClassAs applied to class expressions
• subClassOf applied to class expressions

• unionOf
• intersectionOf
• complementOf

• minCardinality
• maxCardinality
• cardinality

• hasValue Descriptions can include specific value information

• Class: Classes may be described by associating a class name with a description. A trivial example is a class with the name Mammal and with the description THING - which is just the most general class. From this a reasoner can deduce that Mammal is a subclass of Thing. Another example of class description would include a name such as Person and a description Mammal. From this a reasoner could deduce that the class Person is a subclass of the class Mammal and any instance of the class Person is also an instance of the class Mammal. Note, there is no limitation on cycle creation in subclass hierarchies.
• Property: A term that will be used as a relationship between individuals is a property. In this document we use individual to denote instances of classes (e.g., deborah is an instance of person) as well as instances of datatypes (e.g. 4 is an instance of the datatype integer). Examples of properties would include: hasChild, hasRelative, hasSibling, hasAge, etc. The first three would be expected to relate an instance of a class person to another instance of the class person and the last one (hasAge) would be expected to relate an instance of the class person to an instance of the datatype Integer.
• subClassOf: Class hierarchies may be created by stating that classes are subclasses of other classes. For example, the class person could be stated to be a subclass of the class mammal. From this a reasoner may deduce that if X is a person, then X is a mammal.
• subPropertyOf: Property hierarchies may be created by stating that some properties are subproperties of other properties. For example, hasSibling may be stated to be a subproperty of hasRelative. From this a reasoner may deduce that if X is related to Y by the hasSibling property, then X is also related to Y by the hasRelative property.
• domain: Properties may be stated to have domains, (i.e., if X is related to Y by a property p with a domain class, then X must be an instance of the domain class). For example, the property hasChild may be stated to have the domain of Mammal. From this a reasoner may deduce that if X is related to Y by the hasChild property, i.e., Y is the child of X, then X is a Mammal. Note that these are called global restrictions since the restriction is stated on the property and not just on the property when it is associated with a particular class. See the discussion below on local restrictions for more information.
• range: Properties may be stated to have ranges, (i.e., if X is related to Y by a property p with a range class, then Y must be an instance of the range class). For example, the property hasChild may be stated to have the range of Mammal. From this a reasoner may deduce that if Louise is related to Deborah by the hasChild property, i.e., Deborah is the child of Louise, then Deborah is a Mammal. Range is also a global restriction as is domain above. See the discussion below on local restrictions for more information.
• Individual: Individuals may be described as an instance of a class and properties may also be used to relate one individual to another. For example, an individual named Deborah may be described as an instance of the class person and the property hasEmployer may be used to relate the individual Deborah to the individual StanfordUniversity.

• sameClassAs: Two classes may be stated to be the same (i.e., they may be stated to be different names for the same set of individuals). This can be used e.g., for creating synonymous classes. For example, Car can be stated to be sameClassAs Automobile. From this a reasoner may deduce that any individual that is an instance of Car is also an instance of Automobile and vice versa.
• samePropertyAs: Two properties may be stated to be the same. This may be used to create synonymous properties. For example, hasLeader may be stated to be the samePropertyAs hasHead. From this a reasoner may deduce that if X is related to Y by the property hasLeader, X is also related to Y by the property hasHead and vice versa. The reasoner can also deduce that hasLeader is a subproperty of hasHead and hasHead is a subProperty of hasLeader.
• sameIndividualAs: Two individuals may be stated to be the same. This may be used to create a number of different names that may be used to refer to the same individual. For example, we may state that the individual Deborah is the same individual as DeborahMcGuinness.
• differentIndividualFrom: Two individuals may be stated to be different from each other. For example, the individuals Frank and Deborah may be stated to be different from each other. From this, the reasoner can deduce that Frank and Deborah refer to two unique individuals. Thus, if the individuals Frank and Deborah are both values for a property that is stated to be functional (thus the property has at most one value), then there is a contradiction. Stating differences can be important in systems such as OWL (and RDF) that do not assume that individuals have one and only one name. For example, OWL with no additional information, will not deduce that Frank and Deborah refer to distinct individuals.

• inverseOf: One property may be stated to be the inverse of another property. For example, if the property P1 is stated to be the inverse of the property P2, then if X is related to Y by the P2 property, then Y is related to X by the P1 property. For example, if hasChild is the inverse of hasParent and Deborah hasParent Louise, then a reasoner may deduce that Louise hasChild Deborah.
• transitive: Properties may be stated to be transitive. If a property is transitive, then if the pair (x,y) is an instance of the transitive property P, and the pair (y,z) is an instance of P, then the pair (x,z) is also an instance of P. For example, if ancestor is stated to be transitive, and if Sara is an ancestor of Louise (i.e., (Sara,Louise) is an instance of ancestor) and Louise is an ancestor of Deborah (i.e., (Louise,Deborah) is an instance of ancestor), then a reasoner may deduce that Sara is an ancestor of Deborah (i.e., (Sara,Deborah) is an instance of ancestor.
  The same DAML+OIL side conditions hold that restrict transitive properties (and their superproperties) from having an atmost1 or an exactly1 restriction.
• symmetric: Properties may be stated to be symmetric. If a property is symmetric, then if the pair (x,y) is an instance of the symmetric property P, then the pair (y,x) is also an instance of P. For example, friend may be stated to be a symmetric property. Then a reasoner that is given that Frank is the friend of Deborah can deduce that Deborah is a friend of Frank. Note of course that properties must have appropriate domains and ranges in order to be made symmetric.
• functional : Properties may be stated to be functional. If a property is functional, then it has no more than one value. It may have no values. Another way of saying this is that the property's minimum cardinality is zero and its maximum cardinality is 1. For example, hasPrimaryEmployer may be stated to be functional. If an individual instance of person has a primary employer, then that individual may not have more than one primary employer. This does not state that every person must have at least one primary employer however. This proposal includes the same side condition as is stated in the DAML+OIL specification that does not allow transitive properties nor any of their superproperties to be declared functional. For more information on the details of the limitation, see the Warning under the property element section of the DAML+OIL reference description or in a research paper by Horrocks, Sattler, and Tobies showing the undecidability that would follow from violating this restriction. This name is still under discussion. Please see the Reference Description Document for more information.
• unambiguous (inverse functional): Properties may be stated to be inverse functional. If a property is inverse functional then the inverse of the property is functional. Thus the inverse of the property has at most one value. For example, hasUSSocialSecurityNumber (a unique identifier for United States residents) may be stated to be unambiguous (or inverse functional). The inverse of this (which may be referred to as isTheSocialSecurityNumberFor) has at most one value. Thus any one person's social security number is the only value for their hasUSSocialSecurityNumber property. From this a reasoner may deduce that no two different individual instances of Person have the identical US Social Security Number. Also, a reasoner may deduce that if two instances of Person have the same social security number, then those two instances refer to the same individual. This name is still under discussion. Please see the Reference Description Document for more information.
• allValuesFrom (toClass in DAML+OIL): allValuesFrom is stated on a property with respect to a class. A property on a particular class may have a local range restriction associated with it. This means that if an individual instance of the class is related by the property to a second individual, then the second individual can be inferred to be an instance of the local range restriction class. For example, the class person may have a property called hasOffspring restricted to have allValuesFrom the class person. This means that if an individual person Louise is related by the property hasOffspring to the individual Deborah, then from this a reasoner can deduce that Deborah is an instance of the class person. This allows the property hasOffspring to be used with other classes, possibly the class Cat and have an appropriate value restriction associated with the use of the property on that class. In this case, hasOffspring would have the local range restriction of Cat when associated with the class cat and would have the local range restriction Person when associated with the class Person. Note that the reasoner can not deduce from an allValuesFrom restriction alone that there is at least one value for the property.
• someValuesFrom: (hasClass in DAML+OIL): someValuesFrom is stated on a property with respect to a class. A particular class may have a restriction on a property that at least one value for that property is of a certain type. For example, the class SemanticWebPaper may have a someValuesFrom restriction on the hasKeyword property that states that some value for the hasKeyword property should be an instance of the class SemanticWebTopic. This allows for the option of having multiple keywords and as long as one or more is an instance of the class SemanticWebTopic, then the paper would be consistent with the someValuesFrom restriction. Unlike allValuesFrom, someValuesFrom does not restrict all the values of the property to be instances of the same class. If myPaper is an individual instance of the SemanticWebPaper class, then myPaper is related by the hasKeyword property to at least one individual instance of the SemanticWebTopic class. Note that the reasoner can not deduce (as it could with allValuesFrom restrictions) that all values of hasKeyword are instances of the SemanticWebTopic class

A limited form of cardinality restrictions have been included in OWL Lite. OWL cardinality restrictions are referred to as local restrictions since they are stated on properties with respect to a particular class. That is, the restrictions limit the cardinality of that property on instances of the class. OWL Lite cardinality restrictions are limited because they only allow statements concerning cardinalities of value 0 or 1 (and do not allow arbitrary values for cardinality as is the case in the full OWL language).
• minCardinality: Cardinality is stated on a property with respect to a particular class. If a minCardinality of 1 is stated on a property with respect to a class, then any instance of that class will be related to at least one individual by that property. This is another way of saying that the property is required for all individual instances of the class. For example, the class parent may have a minimum cardinality of 1 on the hasOffspring property. From this a reasoner may deduce that that any individual instance of the class person, such as Louise, is related to at least one individual by the hasOffspring property. From this information alone, the reasoner may not deduce any maximum number of offspring for individual instances of the class parent. In OWL Lite the only minimum cardinalities allowed are 0 or 1. A minimum cardinality of zero on a property just states that (in the absence of any more specific information) that property is optional with respect to a class. For example, the property has Offspring may have a minimum cardinality of zero on the class person (while it is stated to have the more specific information of minimum cardinality of one on the class parent).
• maxCardinality: Cardinality is stated on a property with respect to a particular class. If a maxCardinality of 1 is stated on a property with respect to a class, then any instance of that class will be related to at most one individual by that property. This is sometimes called a "unique property". For example, the property hasRegisteredVotingState on the class UnitedStatesCitizens may have a maximum cardinality of one (because people are only allowed to vote in only one state). From this a reasoner can deduce that individual instances of the class USCitizens may not be related to two or more distinct individuals through the hasRegisteredVotingState property. From a maximum cardinality one restriction alone, a reasoner may not deduce a minimum cardinality of 1. It may be useful to state that certain classes have no values for a particular property. For example, instances of the class UnmarriedPerson should not be related to any individuals by the property hasSpouse. This is represented by a maximum cardinality of zero on the hasSpouse property on the class UnmarriedPerson.
• cardinality: Cardinality is provided as a convenience when it is useful to state that a property on a class has both minCardinality 0 and maxCardinality 0 or both minCardinality 1 and maxCardinality 1. For example, the class person has exactly one value for the property hasBirthMother. From this a reasoner may deduce that no two distinct individual Mothers may be values for the hasBirthMother property of the same person.

• Datatypes will be included in the OWL Lite language. Thus, for example a range could be stated to be XSD:decimal. The exact details of this is dependent upon the RDF core group's decisions on datatypes for RDF. See datatypeProperty and objectTypeProperty in the Reference specification for more information.

• imports: Each imports statement references another OWL ontology containing definitions that apply to the current ontology. Each reference consists of a URI specifying from where the ontology is to be imported from. Imports statements are transitive, that is, if ontology A imports B, and B imports C, then A imports both B and C. Importing an ontology into itself is considered a null action. If ontology A imports B and B imports A, then they are considered to be equivalent.
• Dublin Core MetaData: Ontologies also have a non-logical component (not yet specified) that can be used to record authorship, and other non-logical information associated with a ontology. A prime candidate is to associate with the ontology attributes from the Dublin Core Metadata standard.

• oneOf (enumerated classes): Classes can be described by enumeration of the individuals that make up the class. The members of the class are exactly the set of enumerated individuals; no more, no less. For example, the class of daysOfTheWeek can be described by simply enumerating the individuals Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday. From this a reasoner could deduce the maximum cardinality (7) of any property that has daysOfTheWeek as its allValuesFrom restriction.
• hasValue (property values): A property can be required to have a certain individual as a value (also sometimes referred to as property fillers). For example, instances of the class of dutchCitizens can be characterized as those people that have theNetherlands as a value of their nationality. (Where theNetherlands itself is an instance of the class of all nationalities).
• disjointWith: The full OWL language allows the statement that classes are disjoint, for example stating that man and woman are disjoint classes, that is they are disjoint with each other. From this a reasoner could conclude an inconsistency when an individual is stated to be an instance of both and similarly could deduce that if A is an instance of Man, then A is not an instance of Woman.
• unionOf, complementOf, and intersectionOf (Boolean combinations): OWL allows arbitrary Boolean combinations of classes: IntersectionOf, UnionOf, and complementOf. For example, taking the intersection of the class of Dutch citizens with the class of senior citizens describes the class of Dutch senior citizens. Using complement, we could state that children are not senior citizens (i.e. the class children is a subclass of the complement of senior citizens). Citizenship of the European Union could be described as the union of the citizenship of all member states.
• minCardinality, maxCardinality, cardinality (full cardinality): While in OWL Lite, cardinalities are restricted to at least, at most or exactly 1 or 0, full OWL allows cardinality statements for arbitrary non-negative integers. For example the class of DINKs ("Dual Income, No Kids") would restrict the cardinality of the property hasIncome to a minimum cardinality of two (while the property hasChild would have be restricted to cardinality 0).
• complex class descriptions: In many places, OIL Lite restricts the syntax to single class names (e.g. in subClassOf or equivalentClass statements). Full OWL extends this to allowing in those places arbitrarily complex class descriptions, consisting of enumerated classes, property restrictions, and Boolean combinations of these.

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document is a working document for the use by W3C Members and other interested parties. It may be updated, replaced or made obsolete by other documents at any time.

This document has been produced as part of the W3C Semantic Web Activity, following the procedures set out for the W3C Process. The document has been compiled by the Web Ontology Working Group. The goals of the Web Ontology working group are discussed in the Web Ontology Working Group charter .

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3