[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oil2xsd] DAML+OIL support
|
From: |
Stefan Merten |
|
Subject: |
Re: [oil2xsd] DAML+OIL support |
|
Date: |
Wed, 23 Oct 2002 15:40:46 +0200 |
-----BEGIN PGP SIGNED MESSAGE-----
Hi again!
1 minutes ago Stefan Merten wrote:
> 5 days ago Iryna Gurevych wrote:
>> We find the reference description of DAML+OIL
>> (http://www.daml.org/2001/03/reference) particularly helpful to
>> understand a few differencies in the semantics of OIL and DAML+OIL.
>
> Indeed this seems to be a concise and understandable reference. I
> think it would be good to post it to this list and then discuss the
> necessary changes. I'll give it a start.
Here we go. I'll quote it e-mail like and write my 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>.
> 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.
> 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.
> 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 :-) .
> 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.
> 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;
> * 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.
> * 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.
> * 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?
> * 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?
> * 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.
> 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>. Other boolean combinations are not representable in
XML Schema.
> 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.
> 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.
> 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.
> 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.
> Appendix: Index of all language elements
...
> Notes
...
> References
>
> 1. http://lists.w3.org/Archives/Public/www-rdf-logic/
> 2. http://www.cs.vu.nl/%7Efrankh
> 3. http://www.bell-labs.com/user/pfps
> 4. http://www.cs.man.ac.uk/%7Ehorrocks
> 5. http://www.daml.org/2001/03/daml+oil-walkthru.html
> 6. http://www.daml.org/2001/03/daml+oil.daml
> 7. http://www.daml.org/2001/03/model-theoretic-semantics.html
> 8. http://www.daml.org/2001/03/axiomatic-semantics.html
> 9. file://localhost/sun/merten/tmp/reference.html#Introducto
> 10. file://localhost/sun/merten/tmp/reference.html#Header
> 11. file://localhost/sun/merten/tmp/reference.html#Version
> 12. file://localhost/sun/merten/tmp/reference.html#Imports
> 13. file://localhost/sun/merten/tmp/reference.html#Object
> 14. file://localhost/sun/merten/tmp/reference.html#Class
> 15. file://localhost/sun/merten/tmp/reference.html#Class1
> 16. file://localhost/sun/merten/tmp/reference.html#Enumerated
> 17. file://localhost/sun/merten/tmp/reference.html#Restriction
> 18. file://localhost/sun/merten/tmp/reference.html#Boolean
> 19. file://localhost/sun/merten/tmp/reference.html#Property
> 20. file://localhost/sun/merten/tmp/reference.html#Instances
> 21. file://localhost/sun/merten/tmp/reference.html#Values
> 22. file://localhost/sun/merten/tmp/reference.html#collection
> 23. file://localhost/sun/merten/tmp/reference.html#Index
> 24. file://localhost/sun/merten/tmp/reference.html#Notes
> 25. http://www.w3%20.org/1999/02/22-rdf-syntax-ns
> 26. file://localhost/sun/merten/tmp/reference.html#Syntax
> 27. http://www.daml.org/2001/03/model-theoretic-semantics.html
> 28. http://www.daml.org/2001/03/daml+oil.daml
> 29. file://localhost/sun/merten/tmp/reference.html#Mixing
> 30. file://localhost/sun/merten/tmp/reference.html#Index
> 31. file://localhost/sun/merten/tmp/reference.html#Header
> 32. file://localhost/sun/merten/tmp/reference.html#Class
> 33. file://localhost/sun/merten/tmp/reference.html#Property
> 34. file://localhost/sun/merten/tmp/reference.html#Instance
> 35. file://localhost/sun/merten/tmp/reference.html#Version
> 36. file://localhost/sun/merten/tmp/reference.html#Imports
> 37. file://localhost/sun/merten/tmp/reference.html#Class1
> 38. http://www.w3.org/TR/2000/CR-rdf-schema-20000327
> 39. file://localhost/sun/merten/tmp/reference.html#Class1
> 40. file://localhost/sun/merten/tmp/reference.html#Class1
> 41. file://localhost/sun/merten/tmp/reference.html#Class1
> 42. file://localhost/sun/merten/tmp/reference.html#Class1
> 43. file://localhost/sun/merten/tmp/reference.html#Boolean
> 44. file://localhost/sun/merten/tmp/reference.html#Enumerated
> 45. file://localhost/sun/merten/tmp/reference.html#Enumerated
> 46. file://localhost/sun/merten/tmp/reference.html#Restriction
> 47. file://localhost/sun/merten/tmp/reference.html#Boolean
> 48. file://localhost/sun/merten/tmp/reference.html#Instances
> 49. file://localhost/sun/merten/tmp/reference.html#ObjectProperty
> 50. file://localhost/sun/merten/tmp/reference.html#DatatypeProperty
> 51. file://localhost/sun/merten/tmp/reference.html#Class1
> 52. file://localhost/sun/merten/tmp/reference.html#Instance
> 53. file://localhost/sun/merten/tmp/reference.html#Values
> 54. file://localhost/sun/merten/tmp/reference.html#Class1
> 55. file://localhost/sun/merten/tmp/reference.html#Datatype
> 56. file://localhost/sun/merten/tmp/reference.html#Class1
> 57. file://localhost/sun/merten/tmp/reference.html#Datatype
> 58. file://localhost/sun/merten/tmp/reference.html#Cardinalit
> 59. file://localhost/sun/merten/tmp/reference.html#Class1
> 60. file://localhost/sun/merten/tmp/reference.html#Class1
> 61. file://localhost/sun/merten/tmp/reference.html#Class1
> 62. file://localhost/sun/merten/tmp/reference.html#Boolean1
> 63. file://localhost/sun/merten/tmp/reference.html#Class1
> 64. http://www.w3.org/TR/2000/CR-rdf-schema-20000327
> 65. file://localhost/sun/merten/tmp/reference.html#Restriction
> 66. file://localhost/sun/merten/tmp/reference.html#Class1
> 67. http://www.w3.org/TR/2000/CR-rdf-schema-20000327
> 68. file://localhost/sun/merten/tmp/reference.html#Restriction
> 69. http://www.w3.org/TR/REC-rdf-syntax
> 70. http://www.w3.org/TR/2000/CR-rdf-schema-20000327
> 71. http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
> 72. file://localhost/sun/merten/tmp/reference.html#cardinality-def
> 73. file://localhost/sun/merten/tmp/reference.html#cardinalityQ-def
> 74. file://localhost/sun/merten/tmp/reference.html#Class-def
> 75. file://localhost/sun/merten/tmp/reference.html#complementOf-def
> 76. file://localhost/sun/merten/tmp/reference.html#Datatype
> 77. file://localhost/sun/merten/tmp/reference.html#DatatypeProperty
> 78. file://localhost/sun/merten/tmp/reference.html#DatatypeRestriction
> 79. file://localhost/sun/merten/tmp/reference.html#Value
> 80.
> file://localhost/sun/merten/tmp/reference.html#differentIndividualFrom-def
> 81. file://localhost/sun/merten/tmp/reference.html#Disjoint-def
> 82. file://localhost/sun/merten/tmp/reference.html#disjointUnionOf-def
> 83. file://localhost/sun/merten/tmp/reference.html#disjointWith-def
> 84. file://localhost/sun/merten/tmp/reference.html#domain-def
> 85. file://localhost/sun/merten/tmp/reference.html#equivalentTo-def
> 86. file://localhost/sun/merten/tmp/reference.html#hasClass-def
> 87. file://localhost/sun/merten/tmp/reference.html#hasClassQ-def
> 88. file://localhost/sun/merten/tmp/reference.html#hasValue-def
> 89. file://localhost/sun/merten/tmp/reference.html#imports-def
> 90. file://localhost/sun/merten/tmp/reference.html#intersectionOf-def
> 91. file://localhost/sun/merten/tmp/reference.html#inverseOf-def
> 92. file://localhost/sun/merten/tmp/reference.html#maxCardinality-def
> 93. file://localhost/sun/merten/tmp/reference.html#maxCardinalityQ-def
> 94. file://localhost/sun/merten/tmp/reference.html#minCardinality-def
> 95. file://localhost/sun/merten/tmp/reference.html#minCardinalityQ-def
> 96. file://localhost/sun/merten/tmp/reference.html#ObjectClass
> 97. file://localhost/sun/merten/tmp/reference.html#ObjectProperty
> 98. file://localhost/sun/merten/tmp/reference.html#ObjectRestriction
> 99. file://localhost/sun/merten/tmp/reference.html#oneOf-def
> 100. file://localhost/sun/merten/tmp/reference.html#onProperty-def
> 101. file://localhost/sun/merten/tmp/reference.html#Ontology-def
> 102. file://localhost/sun/merten/tmp/reference.html#Property-def
> 103. file://localhost/sun/merten/tmp/reference.html#range-def
> 104. file://localhost/sun/merten/tmp/reference.html#Restriction-def
> 105. file://localhost/sun/merten/tmp/reference.html#sameClassAs-def
> 106. file://localhost/sun/merten/tmp/reference.html#sameIndividualAs-def
> 107. file://localhost/sun/merten/tmp/reference.html#samePropertyAs-def
> 108. file://localhost/sun/merten/tmp/reference.html#subClassOf-def
> 109. file://localhost/sun/merten/tmp/reference.html#subPropertyOf-def
> 110. file://localhost/sun/merten/tmp/reference.html#toClass-def
> 111. file://localhost/sun/merten/tmp/reference.html#TransitiveProperty-def
> 112. file://localhost/sun/merten/tmp/reference.html#UnambigousProperty-def
> 113. file://localhost/sun/merten/tmp/reference.html#unionOf-def
> 114. file://localhost/sun/merten/tmp/reference.html#UniqueProperty-def
> 115. file://localhost/sun/merten/tmp/reference.html#versionInfo-def
> 116. file://localhost/sun/merten/tmp/reference.html#Cardinalit
> 117. http://www.daml.org/2001/03/daml+oil-ex.daml
> 118. http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#abbreviatedSyntax
Any comments?
Grüße
Stefan
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAgUBPbam3QnTZgC3zSk5AQFRYwP5AcA2gbiSarUSd3LoINtbhVT7hRnpspK+
eNWZ7Y8B619Jl18XDS+lp3aKp5x6/hXUxsceviqXlpeUSXWaJvqMVedAE4djfq0Z
590aSvYPHPcub/s/MT38Zl8bjfM2zaPRusPd8HZFEWe8j8NAdxz5MtTVqGUZJS/C
Gcod2xUIJyM=
=Rl5S
-----END PGP SIGNATURE-----