[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oil2xsd] DAML+OIL support
|
From: |
Iryna Gurevych |
|
Subject: |
Re: [oil2xsd] DAML+OIL support |
|
Date: |
Thu, 28 Nov 2002 14:42:13 +0100 |
Hi Stefan,
here is my contribution.
I will insert the comments in-between ~~~~~~~~~~~~
> Reference description of the
> DAML+OIL (March 2001) ontology markup language
>
> Feedback to [1]www-rdf-logic, please.
> DAML+OIL (March 2001) version (revision 4.2): [2]Frank van Harmelen,
> [3]Peter F. Patel-Schneider and [4]Ian Horrocks, editors.
>
> Contributors: Tim Berners-Lee, Dan Brickley, Dan Connolly, Mike Dean,
> Stefan Decker, Pat Hayes, Jeff Heflin, Jim Hendler, Ora Lassila, Deb
> McGuinness, Lynn Andrea Stein, ...
>
> Abstract
>
> DAML+OIL is a semantic markup language for Web resources. It builds on
> earlier W3C standards such as RDF and RDF Schema, and extends these
> languages with richer modelling primitives. DAML+OIL provides
> modelling primitives commonly found in frame-based languages. DAML+OIL
> (March 2001) extends DAML+OIL (December 2000) with values from XML
> Schema datatypes. The language has a clean and well defined semantics.
>
> This document gives a systematic, compact and informal description of
> all the modelling primitives of DAML+OIL (March 2001). We expect this
> document to serve as a reference guide for users of the DAML+OIL
> language.
> * Readers unfamiliar with DAML+OIL should first consult the
> [5]DAML+OIL walkthrough for a more narrative description of an
> example use of the language.
> * The normative reference on the precise syntax of the language
> constructs is the machine readable [6]RDF Schema definition of
> DAML+OIL.
> * Two references that give a precise definition of the meaning of
> the language constructs are the [7]model-theoretic semantics and
> the [8]KIF axiomatization.
>
> Contents
>
> * [9]Introductory remarks
> * [10]Header
> * [11]Version information
> * [12]Imports
> * [13]Objects and Datatype Values
> * [14]Class elements
> * [15]Class expressions
> * [16]Enumerations
> * [17]Property restrictions
> * [18]Boolean combination of class expressions
> * [19]Property elements
> * [20]Instances
> * [21]Datatype Values
> * [22]rdf:parseType="daml:collection"
> * [23]Index of all language elements
> * [24]Notes
>
> Introductory remarks
>
> A DAML+OIL knowledge base is a collection of RDF triples. DAML+OIL
> prescribes a specific meaning for triples that use the DAML+OIL
> vocabulary. This document informally specifies which collections of
> RDF triples constitute the DAML+OIL vocabulary and what the prescribed
> meaning of such triples is.
>
> Different syntactic forms
>
> As with any set of RDF triples, DAML+OIL triples can be represented in
> many different syntactic forms (as described in the [25]RDF
> specification). The current document uses a specific RDF syntactic
> form for these triples. However, it is also allowed to use any other
> syntactic RDF form that results in the same underlying set of RDF
> triples as the syntax used in this document. Such other syntactic form
> would then carry exactly the same prescribed meaning as the equivalent
> syntactic form used in this document. See [26]Syntax Note for an
> example of this.
>
> Mixing DAML+OIL with arbitrary RDF
>
> As stated above, DAML+OIL assigns a specific meaning to certain RDF
> triples. The [27]model-theoretic semantics specifies exactly which
> triples are assigned a specific meaning, and what this meaning is.
> DAML+OIL only provides a semantic interpretation for those parts of an
> RDF graph that instantiate the schema defined in [28]daml+oil.daml.
> Any additional RDF statements, resulting in additional RDF triples are
> perfectly allowed, but DAML+OIL is silent on the semantic consequences
> (or lack thereof) of such additional triples. See [29]Mixing Note for
> an example of this. The KIF axiomatization provides a meaning for all
> RDF triples, but non DAML+OIL triples are only modelled as triples,
> nothing deeper.
>
> Language structure
>
> A DAML+OIL ontology is made up of several components, some of which
> are optional, and some of which may be repeated. See [30]the index for
> a listing of all these components. Througout this document, DAML+OIL
> constructs will be presented in a structured format, and not as bare
> RDF triples. This structured RDF format is more natural to read, but,
> of course, any way of generating the same RDF triples as generated by
> the structured RDF format is equivalent.
>
> A DAML+OIL ontology consists of zero or more [31]headers, followed by
> zero or more [32]class elements, [33]property elements, and
> [34]instances.
>
> Header
>
> An daml:Ontology element contains zero or more [35]version information
> and [36]imports elements.
> <Ontology rdf:about="">
> <versionInfo>$Id: reference.html,v 1.10 2001/04/11 16:27:53 mdean Exp
> $</vers
Stefan>
> <rdfs:comment>An example ontology</rdfs:comment>
> <imports rdf:resource="http://www.daml.org/2001/03/daml+oil"/>
> </Ontology>
>
> Version information
>
> The daml:versionInfo element generally contains a string giving
> information about this version, for example RCS/CVS keywords. This
> element does not contribute to the logical meaning of the ontology.
> See the example above.
The version information could be part of a global <annotation>.
~~~~~~~~~~~~~~
Yes.
~~~~~~~~~~~~~~
> Imports
>
> Each daml:imports statement references another DAML+OIL ontology
> containing definitions that apply to the current DAML+OIL resource.
> Each reference consists of a URI specifying from where the ontology is
> to be imported from. See the example above. 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, so if ontology A imports B and B imports A, then they
> are considered to be equivalent.
>
> Note that namespaces only provide a mechanism for creating unique
> names for elements, and do not actually include definitions in the way
> that imports does. Similarly, imports statements do not set up a
> shorthand notation for names. Therefore, it is common to have imports
> statements that correspond to each namespace. However, additional
> imports may be used for ontologies that provide definitions without
> introducing any new names.
<daml:imports> could be represented by a <xsd:include> or
<xsd:import>. However, for a start I'd say this is not supported by
early versions.
~~~~~~~~~~~~~~
This is not currently supported. However, this might be a nice feature to allow
modularization of the ontology, i.e. you can split it up in separate reusable
ontologies describing specific domains.
~~~~~~~~~~~~~~
> Objects and Datatype Values
>
> DAML+OIL divides the universe into two disjoint parts. One part
> consists of the values that belong to XML Schema datatypes.
This is great and allows us to remove some hacks which did introduce
XML Schema datatypes until now.
~~~~~~~~~~~~~~
Until now XML (and M3L) Schema datatypes have had to be modelled as individuals
in the OIL ontology.
My pilot investigations with OilEd3.4 showed that only simple, atomic types,
like integer, string, real, anyUri, date, and boolean can be employed as range
definitions. Now, it is not clear whether this is a restriction imposed by the
editor, or a more general problem, i.e. XML Schema datatype values that can be
given are a pre-defined subset of all possible values.
Possibly, the problem can be solved via namespaces, but this has to be
investigated properly.
Otherwise, we will have to model the XML/M3L/XXL datatypes as before.
~~~~~~~~~~~~~~
> This part
> is called the datatype domain. The other part consists of (individual)
> objects that are considered to be members of classes described within
> DAML+OIL (or RDF). This part is called the object domain.
>
> DAML+OIL is mostly concerned with the creation of classes that
> describe (or define) part of the object domain. Such classes are
> called object classes and are elements of daml:Class, a subclass of
> rdfs:Class. DAML+OIL (March 2001) also allows the use of XML Schema
> datatypes to describe (or define) part of the datatype domain. These
> datatypes are used within DAML+OIL simply by including their URIs
> within a DAML+OIL ontology. They are (implicitly) elements of
> daml:Datatype. Datatypes are not DAML+OIL individual objects.
So in a sense a `daml2xsd' would only transform the object domain into
the datatype domain :-) .
~~~~~~~~~~~~~~
Yes.
~~~~~~~~~~~~~~
> Class elements
>
> A class element, daml:Class, contains (part of) the definition of an
> object class. A class element refers to a class name (a URI), (we will
> refer to this class as C) and contains
> * zero or more rdfs:subClassOf elements (each containing a
> [37]class-expression).
> Each subClassOf element asserts that C is a subclass of the
> class-expression mentioned in the element. (Each class-expression
> defines a (possibly anonymous) class).
This would mean multiple inheritance which is not possible in XML
Schema. Thus at most one `daml:subClassOf' element will be permitted.
~~~~~~~~~~~~~~
Yes. This is a constraint on the modeling side: only unary inheritance is
allowed.
~~~~~~~~~~~~~~
> Warning: The [38]RDF Schema specification demands that the
> subclass-relation between classes must be acyclic. We believe this
> to be too restrictive, since a cycle of subclass relationships
> provides a useful way to assert equality between classes.
> Consequently, DAML+OIL (March 2001) places no such restriction on
> the subClassOf relationship between classes;
~~~~~~~~~~~~~~
Are cycles allowed by XML Schema? I.e. datatype A extends datatype B, and
datatype B extends datatype A?
If not, either this is going to become another constaint on the modeling side
(which is not good), or we need a way to deal with that in the transformation.
~~~~~~~~~~~~~~
> * zero or more daml:disjointWith elements (each containing a
> [39]class-expression).
> Each disjointWith element asserts that C is disjoint with the
> class-expression in the element (ie. C must have no instances in
> common with it);
IMHO this is important only for the ontology and need not be expressed
in XML Schema.
~~~~~~~~~~~~~~
Yes. As instances of the ontology per se are not translated to XML Schema, we
don't need to translate the statements making sense in the context of reasoning
about instances.
~~~~~~~~~~~~~~
> * zero or more daml:disjointUnionOf elements (each containing a list
> of [40]class-expressions).
> Each disjointUnionOf element asserts that C has the same instances
> as the disjoint union of the class-expressions element. More
> precisely: all of the classes defined by the class-expressions of
> a disjointUnionOf element must be pairwise disjoint (i.e. there
> can be no individual that is an instance of more than one of the
> class expressions in the list.), and their union must be equal to
> C;
Dito.
~~~~~~~~~~~~~~
Yes. S. above.
~~~~~~~~~~~~~~
> * zero or more daml:sameClassAs elements (each containing a
> [41]class-expression).
> Each sameClassAs element asserts that C is equivalent to the
> class-expression in the element (ie. C and all the
> class-expression must have the same instances);
Dito?
~~~~~~~~~~~~~~
Yes. S. above.
~~~~~~~~~~~~~~
> * zero or more daml:equivalentToelements (each containing a
> [42]class expression)
> When applied to a class, the equivalentTo element has the same
> semantics as the sameClassAs element.
> Warning: the use of sameClassAs is favoured over the use of
> equivalentTo, since sameClassAs is declared as a subProperty of
> subClassOf, while equivalentTo is not. This makes the meaning of
> sameClassAs at least partly available to an RDF Schema-only agent,
> while the meaning of equivalentTo is completely opaque to such an
> agent.
Dito?
~~~~~~~~~~~~~~
Yes. S. above.
~~~~~~~~~~~~~~
> * zero or more [43]boolean combinations of class expressions.
> The class C must be equivalent to the class defined by each of the
> boolean class expression,
> and
See below.
> * zero or more [44]enumeration elements.
> Each enumeration element asserts that C contains exactly the
> instances enumerated in the element (i.e: no more, no less).
> Although it is formally allowed to have multiple such assertions
> about C, as soon as two of the enumerations are not equivalent,
> the class C immediately becomes inconsistent (since C cannot be
> equivalent to both of these enumerations at once).
See below.
> Notice that the first two elements state necessary but not sufficient
> conditions for class membership. The final four elements state both
> necessary and sufficient conditions.
>
> Class expressions
>
> A class expression is the name used in this document for either
> * a class name (a URI), or
This is the easy part.
> * an [45]enumeration, enclosed in <daml:Class>...</daml:Class> tags,
> or
This will be easy, too, I guess. However, we need named enumerations.
> * a [46]property-restriction, or
See below.
> * or a [47]boolean combination of class expressions, enclosed in
> <rdfs:Class>...</rdfs:Class> tags
See below.
> Each class expression either refers to a named class, namely the class
> that is identified by the URI, or implicitly defines an anonymous
> class, respectively the class that contains exactly the enumerated
> elements, or the class of all instances which satisfy the
> property-restriction, or the class that satisfies the boolean
> combination of such expressions.
In general I guess we won't support arbitrary class expressions.
Class names and enumerations will be supported, however.
> Two class names are already predefined, namely the classes daml:Thing
> and daml:Nothing. Every object is a member of daml:Thing, and no
> object is a member daml:Nothing. Consequently, every class is a
> subclass of daml:Thing and daml:Nothing is a subclass of every class.
>
> Enumerations
>
> An enumeration is a daml:oneOf element, containing a list of the
> objects that are its [48]instances.
> This enables us to define a class by exhaustively enumerating its
> elements. The class defined by the oneOf element contains exactly the
> enumerated elements, no more, no less. For example:
> <daml:oneOf parseType="daml:collection">
> <daml:Thing rdf:about="#Eurasia"/>
> <daml:Thing rdf:about="#Africa"/>
> <daml:Thing rdf:about="#North_America"/>
> <daml:Thing rdf:about="#South_America "/>
> <daml:Thing rdf:about="#Australia"/>
> <daml:Thing rdf:about="#Antarctica"/>
> </oneOf>
This seems to be similar to what we have already. However, to me it
looks like having clearer semantics than what we have.
> Property restrictions
>
> A property restriction is a special kind of class expression. It
> implicitly defines an anonymous class, namely the class of all objects
> that satisfy the restriction. There are two kinds of restrictions. The
> first kind, ObjectRestriction, works on [49]object properties, i.e.,
> properties that relate objects to other objects. The second kind,
> DatatypeRestriction, works on [50]datatype properties, i.e.,
> properties that relate objects to datatype values. Both kinds of
> restrictions are created using the same syntax, with the usual
> difference being whether a class element or a datatype reference is
> used. It is also possible to create restrictions that are neither
> restrictions nor datatype restrictions, but these restrictions are not
> handled within DAML+OIL.
>
> A daml:Restriction element contains an daml:onProperty element, which
> refers to a property name (a URI) (we will refer to this property as
> P) and one or more of the following
> * elements indicating the type of restriction:
> + a daml:toClass element (which contains a [51]class expression
> ).
> A toClass element defines the class of all objects for whom
> the values of property P all belong to the class expression.
> In other words, it defines the class of object x for which it
> holds that if the pair (x,y) is an instance of P, then y is
> an instance of the class-expression or datatype;
> + a daml:hasValue element (which contains (a reference to)
> [52]an individual object or a [53]datatype value).
> A hasValue element defines the class of all objects for whom
> the property P has at least one value equal to the named
> object or datatype value (and perhaps other values as well).
> In other words, if we call the instance y, then it defines
> the class of objects x for which (x,y) is an instance of P;
> + A daml:hasClass element (which contains a [54]class
> expression or a [55]datatype references).
> A hasClass element defines the class of all objects for which
> at least one value of the property P is a member of the class
> expression or datatype. In other words, it defines the class
> of objects x for which there is at least one instance y of
> the class-expression or datatype such that (x,y) is an
> instance of P. This does not exclude that there are other
> instances (x,y') of P for which y' does not belong to the
> class expression or datatype.
> Notice that a toClass restriction is analogous to the universal
> (for-all) quantifier of Predicate logic - for each instance of the
> class or datatype that is being defined, every value for P must
> fulfill the restriction. The hasClass restriction is analogous to
> the existential quantifier of Predicate logic - for each instance
> of the class or datatype that is being defined, there exists at
> least one value for P that fulfils the restriction.
> Also notice that the correspondence of toClass with the universal
> quantifier means that a toClass restriction for a property P is
> trivially satisfied for an instance that has no value for property
> P at all. To see why this is so, observe that the toClass
> restriction demands that all values of P belong to class P, and if
> no such values exist, the restriction is trivially true.
> * elements containing a non-negative integer (to which we will refer
> as N) indicating an unqualified cardinality restriction:
> + a daml:cardinality element.
> This defines the class of all objects that have exactly N
> distinct values for the property P, i.e. x is an instance of
> the defined class if and only if there are N distinct values
> y such that (x,y) is an instance of P;
> + a daml:maxCardinality element.
> This defines the class of all objects that have at most N
> distinct values for the property P;
> + a daml:minCardinality element.
> This defines the class of all objects that have at least N
> distinct values for the property P.
> * elements containing a non-negative integer (to which we will refer
> as N)indicating a qualified cardinality restriction, and
> containing a daml:hasClassQ element, containing a [56]class
> expression or a [57]datatype references:
> + a daml:cardinalityQ element.
> This defines the class of all objects that have exactly N
> distinct values for the property P that are instances of the
> class expression or datatype (and possibly other values not
> belonging to the class expression or datatype). In other
> words: x is an instance of the defined class (x satisfies the
> restriction) if and only if there are exactly N distinct
> values y such that (x,y) is an instance of P and y is an
> instance of the class expression or datatype;
> + a daml:maxCardinalityQ element.
> This defines the class of all objects that have at most N
> distinct values for the property P that are instances of the
> class expression or datatype (and possibly other values not
> belonging to the class expression or datatype);
> + a daml:minCardinalityQ element.
> This defines the class of all objects that have at least N
> distinct values for the property P that are instances of the
> class expression or datatype (and possibly other values not
> belonging to the class expression or datatype).
> Of course a cardinality constraint is simply shorthand for a pair
> of minCardinality and maxCardinality constraints with equal values
> of N (and similarly for cardinalityQ).
> Warning: in order to avoid "exposed content" (i.e., to hide
> DAML+OIL annotations from browsers), it is necessary to write
> cardinality constraints in an alternative RDF format. See
> [58]Cardinality Syntax Notefor an example of this.
>
> When there are multiple restrictions listed as part of a single
> Restriction element, the property P has to satisfy all of the
> restrictions (i.e., multiple restrictions are read as a conjunction).
>
> Notice that the restrictedBy element which was associated with
> slot-restrictions in earlier versions of the language has now been
> removed, since it is completely synonymous with subClassOf.
I have to check that section later. I think I need to look at the
current code to understand. However, it sounds as if we do it already
this way.
~~~~~~~~~~~~~~
Yes, that's approximately what we do. I am not sure whether the cardinality is
properly translated in all the variations possible.
~~~~~~~~~~~~~~
> Boolean combination of class expressions
>
> A boolean combination of class expressions can be constructed from:
> * an daml:intersectionOf element, containing a list of [59]class
> expressions.
> This defines the class that consists of exactly all the objects
> that are common to all class expressions from the list. It is
> analogous to logical conjunction;
> * a daml:unionOf element, containing a list of [60]class
> expressions.
> This defines the class that consists exactly of all the objects
> that belong to at least one of the class expressions from the
> list. It is analogous to logical disjunction;
> * a daml:complementOf element, containing a single [61]class
> expression.
> This defines the class that consists of exactly all objects that
> do not belong to the class expression. It is analogous to logical
> negation, but restricted to objects only.
>
> Note that arbitrarily complex combinations of these expressions can be
> formed.See [62]Boolean Notefor an example of this.
At the moment we support only <oils:Or> which seems to be
<daml:unionOf>.
~~~~~~~~~~~~~~
Yes. Probably, multiple same objects belonging to different classes have to be
filtered out in the resulting choice to avoid duplication of objects.
~~~~~~~~~~~~~~
Other boolean combinations are not representable in
XML Schema.
~~~~~~~~~~~~~~
We dear question that. :-)
Maybe, we could re-think this part. The modeling power of the ontology is quite
restricted, if the boolean combinations of classes may not be used. :-(
For the daml:intersectionOf, it seems to be possible to infer which objects are
common to all class expressions in the list and include only those in the
choice of the resulting And_XXX datatype.
For the daml:complementOf , it seems to be possible to infer all objects,
except the one in question and include only those in the choice of the
resulting Not_XXX datatype.
~~~~~~~~~~~~~~
> Property elements
>
> A rdf:Property element refers to a property name (a URI) (to which we
> will refer as P). Properties that are used in property restrictions
> should be either properties, which relate objects to other objects,
> and are instances of ObjectProperty; or datatype properties, which
> relate objects to datatype values, and are instances of
> DatatypeProperty.
>
> A property element contains:
> * zero or more rdfs:subPropertyOf elements, each containing a
> property name.
> Each subPropertyOf element states that P is a subproperty of the
> property named in the element. This means that every pair (x,y)
> that is an instance of P is also an instance of the named
> property;
> * zero or more rdfs:domain elements (each containing a [63]class
> expression).
> Each domain element asserts that the property P only applies to
> instances of the class expression of the element. More formally:
> if a pair (x,y) is an instance of P, then x is an instance of the
> class expression. This implies that multiple domain expressions
> restrict the domain of P to the intersection of the class
> expressions.
> Warning: This is contrary to the semantics of the domain element
> in the [64]RDF Schema specification, which we believe to be
> flawed. Note that unlike any of the [65]property restrictions
> mentioned above, these domain restrictions are global. The
> property restrictions above are part of a class element, and are
> only enforced on the property when applied to that class. In
> contrast, domain restrictions apply to the property irrespective
> of the Class to which it is applied. This is by virtue of their
> semantics in RDF Schema;
> Because of this, domain elements should be used with great care in
> DAML+OIL.
> * zero or more rdfs:range elements (each containing a [66]class
> expression).
> Each range element asserts that the property P only assumes values
> that are instances of the class expression of the element. More
> formally: a pair (x,y) can only be an instance of P if y is an
> instance of the class expression.
> Warning: Although the [67]RDF Schema specification only allows one
> range restriction for each property, it seems quite natural to
> allow multiple range restrictions. These would then again be
> interpreted as saying that the range of P must be the intersection
> of all the class expressions. Furthermore, as with domain
> restrictions, range restrictions are global, by virtue of RDF
> Schema;
> Because of this, range elements should be used with great care in
> DAML+OIL.
> * zero or more daml:samePropertyAs elements (each containing a
> property name).
> Each samePropertyAs element asserts that P is equivalent to the
> named property (i.e. they must have the same instances),
> * zero or more equivalentTo elements (each containing a property
> name).
> When applied to a property, the equivalentTo element has the same
> semantics as the samePropertyAs element;
> Warning: the use of samePropertyAs is favoured over the use of
> equivalentTo, since samePropertyAs is declared as a subProperty of
> subPropertyOf, while equivalentTo is not. This makes the meaning
> of samePropertyAs at least partly available to an RDF Schema-only
> agent, while the meaning of equivalentTo is completely opaque to
> such an agent.
> and
> * zero or more daml:inverseOf elements (each containing a property
> name), for properties only.
> Each inverseOf element asserts that P is the inverse relation of
> the named property. More formally: if the pair (x,y) is an
> instance of P, than the pair (y,x) is an instance of the named
> property.
>
> Instead of an object property or datatype property element, it is also
> possible to use any of the following elements, each of which assert
> additional information about the property:
> * a daml:TransitiveProperty element, which is a subclass of
> ObjectProperty.
> This asserts that P is transitive, i.e: if the pair (x,y) is an
> instance of P, and the pair (y,z) is an instance of P, then the
> pair (x,z) is also an instance of P;
> * a daml:UniqueProperty element.
> This asserts that P can only have one (unique) value y for each
> instance x, i.e: there cannot be two distinct instances y1 and y2
> such that the pairs (x,y1) and (x,y2) are both instances of P. Of
> course, this is a shorthand notation for the maxCardinality
> restriction of 1,
> or
> * an daml:UnambigousProperty element, which is a subclass of
> ObjectProperty.
> This asserts that an instance y can only be the value of P for a
> single instance x, i.e: there cannot be two distinct instances x1
> and x2 such that both (x1,y) and (x2,y) are both instances of P.
> Notice that the inverse property of a UniqueProperty is always an
> UnambigousProperty and vice versa.
>
> Notice that UniqueProperty and UnambiguousProperty specify global
> cardinality restrictions. That is, no matter what class the property
> is applied to, the cardinality constraints must hold, unlike the
> various cardinality properties used in [68]property restrictions,
> which are part of a class element, and are only enforced on the
> property when applied to that class.
> A property is a binary relation that may or may not be defined in the
> ontology. If it is not defined, then it is assumed to be a binary
> relation with no globally applicable constraints, i.e. any pair with
> first element an object and second element an object or datatype value
> could be an instance of the property.
> Warning: If a transitive property (or any of its superproperties) is
> used in a cardinality constraint, then class consistency is no longer
> necessarily decidable. Of course, UniqueProperty is a a particular
> case of a cardinality constraint.
I have to check that section again looking into the code. Did we
support that? I don't think so.
~~~~~~~~~~~~~~
We never supported the transformation of properties as such, as compared to the
transformation of property restrictions as part of the class definition which
we do support.
That is the transformation of properties would be a completely new dimension.
And this could be a great feature, as it would enable to encode additional new
knowledge from the ontology about properties as such, hierarchicality of
properties, domains, ranges etc. in XML Schema, independently of how a given
property is used as a part of class expression.
The implementation of this feature might however be costly in terms of time.
So, if we decide to do that, the issues raising should be discussed separately.
~~~~~~~~~~~~~~
> Instances
>
> Instances of both classes (i.e., objects) and of properties (i.e.,
> pairs) are written in [69]RDF and [70]RDF Schema syntax.
> See the specification of these languages for more details on the
> various syntactic forms that are allowed. Here we list just some of
> the most common notations:
> <continent rdf:ID="Asia"/>
>
> <rdf:Description rdf:ID="Asia">
> <rdf:type>
> <rdfs:Class rdf:about="#continent"/>
> </rdf:type>
> </rdf:Description>
>
> <rdf:Description rdf:ID="India">
> <is_part_of rdf:resource="#Asia"/>
> </rdf:Description>
>
> There is no unique name assumption for objects in DAML+OIL. To state
> that objects are the same, a daml:sameIndividualAs element is used.
> (Note that daml:equivalentTo can be also used here, but
> daml:sameIndividual is preferred. To state that objects are distinct,
> a daml:differentIndividualFrom element is used. The situation is
> different for datatype values, where XML Schema Datatype identity is
> used.
This is already supported and results in <xsd:enumeration>s.
~~~~~~~~~~~~~~
What we actually support is combining individuals which are instances of a
common class into XML Schema simple types. We do not really translate any
knowledge about the instances. This might be a new extension to be considered.
~~~~~~~~~~~~~~
> Datatype Values
>
> Datatype values are written in a manner that is valid RDF syntax, but
> which is given a special semantics in DAML+OIL. The preferred method
> is to give a lexical representation of the value as a string, along
> with an XML Schema datatype that is used to provide the type of the
> value as well as the parsing mechanism to go from the string to the
> value itself. The XML Schema datatype is the rdf:type of the value,
> and the lexical representation is the rdf:value of the value. So the
> decimal 10.5 could be input as <xsd:decimal rdf:value="10.5"> provided
> that xsd was defined as the URI of the XML Schema Datatype
> specification.
>
> As a nod to backward compatability, literals that occur outside this
> sort of construction are interpreted as any of the XML Schema Datatype
> values with this lexical representation. These values are mostly
> unusable unless some typing information is available, such as a range
> for a property.
>
> The question of whether any XML Schema datatype can be used in such
> constructions, or whether only certain XML Schema dataypes can be so
> used (such as only the predefined datatypes), remains open.
So we have to take care to integrate that correctly.
~~~~~~~~~~~~~~
As noted somewhere above, integration of XML Schema datatypes into a DAML
ontology seems to be a problem right at the moment.
~~~~~~~~~~~~~~
> rdf:parseType="daml:collection"
>
> DAML+OIL needs to represent unordered collections of items (also known
> as bags, or multisets) in a number of constructions, such as
> intersectionOf, unionOf, oneOf, disjointUnionOf and Disjoint. DAML+OIL
> exploits the rdf:parseType attribute to extend the syntax for RDF with
> a convenient notation for such collections. Whenever an element has
> the rdf:parseType attribute with value "daml:collection", the enclosed
> elements must be interpreted as elements in a list structure,
> constructed using the elements List, first, rest and nil.
>
> For example, the statement
> <oneOf rdf:parseType="daml:collection">
> <Thing rdf:resource="#red"/>
> <Thing rdf:resource="#white"/>
> <Thing rdf:resource="#blue"/>
> </oneOf>
>
> should be interpreted as the following construction (also known as a
> consed-pair construction, from Lisp-lore):
> <List>
> <first>
> <Thing rdf:resource="#red">
> </first>
> <rest>
> <List>
> <first>
> <Thing rdf:resource="#white">
> </first>
> <rest>
> <List>
> <first>
> <Thing rdf:resource="#blue">
> </first>
> <rest>
> <List rdf:resource="http://www.daml.org/2001/03/daml+oil#nil";>
> </rest>
> </List>
> </rest>
> </List>
> </rest>
> </List>
>
> Current RDF parsers ([71]RDF specification of February '99) will not
> support the daml:collection parseType. In order to process DAML+OIL
> documents, such parsers will have to be extended, or a separate
> preprocessing stage is required which translates the first form above
> into the second before the DAM+OIL code is given as input to the RDF
> parser.
>
> Note that structures of parseType daml:collection are intended to
> represent unordered collections, even though the RDF datastructure
> imposes a specific order on the elements.
I guess we already do it that way.
~~~~~~~~~~~~~~
Did we really employ *collection's* in the OIL ontology?
~~~~~~~~~~~~~~
>Any comments?
~~~~~~~~~~~~~~
Quite a lot of stuff to think over....
Best,
Iryna
_______________________________________________
oil2xsd-list mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/oil2xsd-list
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [oil2xsd] DAML+OIL support,
Iryna Gurevych <=