W3C

RIF Combination with XML data

W3C Editor's Draft 429 September 2009

This version:
http://www.w3.org/2005/rules/wg/draft/ED-rif-xml-data-20090904/http://www.w3.org/2005/rules/wg/draft/ED-rif-xml-data-20090929/
Latest editor's draft:
http://www.w3.org/2005/rules/wg/draft/rif-xml-data/
Previous version:
http://www.w3.org/2005/rules/wg/draft/ED-rif-xml-data-20090904/ (color-coded diff)
Editors:
Christian de Sainte Marie, IBM

This document is also available in these non-normative formats: PDF version.

Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document, developed by the Rule Interchange Format (RIF) Working Group, specifies how a RIF document can be combined with XML data sources.

Status of this Document

May Be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is being published as one of a set of 10 documents:

  1. RIF Overview
  2. RIF Core Dialect
  3. RIF Basic Logic Dialect
  4. RIF Framework for Logic Dialects
  5. RIF RDF and OWL Compatibility
  6. RIF Datatypes and Built-Ins 1.0
  7. RIF Production Rule Dialect
  8. RIF Use Cases and Requirements RIFTest Cases
  9. RIF Combination with XML data (this document)
  10. OWL 2 RL in RIF

First Public Working Draft

@@@UPDATE @@@ Include-in-this-round?This new draft specifies how RIF rules can be used with XML data. Although conceptually similar to RIF RDF and OWL Compatibility, and serving a parallel function, it is being developed later in the life of the Working Group and is not expect to reach Recommendation at the same time as the other Rec-Track RIF documents.

Please Comment By 2327 October 2009

The Rule Interchange Format (RIF) Working Group seeks public feedback on this First Public Working Draft. Please send your comments to public-rif-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document and see if the relevant text has already been updated.

No Endorsement

Publication as a Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

Overview

This document specifies how a RIF document can be combined with XML data sources. It specifiesdefines a partial implementationdata model for XML instance documents, that is a simplified version of the XQuery 1.0 and XPath 2.0 Data Model [XDM ] that uses a subset of], and it specifies how the RIF condition language.language can be interpreted with respect to an XML data source, and what is the associated semantics, in accordance with that data model.

The XQuery 1.0 and XPath 2.0 Data Model (XDM) specifies what information is accessible in a collection of XML documents, but it does not specify the language used to represent or access the data: this document specifies howan implementation, using the RIF condition language, of a subsetsimplified version of the XDM. This makes the RIF condition language can be interpreted with respectcomparable to an XML data source, and what is the associated semantics, in accordance withother implementations of the XQuery 1.0 andXDM, such as [XPath 2.0 Data Model.] and [XQuery 1.0].

Essentially, this document specifies:

Like the XQuery 1.0 and XPath 2.0 Data Model, the simplified version used in this document supports the following classes of XML documents:

Followingly,Accordingly, this document specifies how a RIF document is combined with well-formed XML data sources and, possible,where available, the corresponding XML schemas are combined with a RIF document,schemas, identified using the Import construct from RIF.rif:Import construct.

However, an instance of the data model can also be constructed from non-XML sources such as relational tables in a database or object instances. In this case, the relevant parts of thedata model are representedis represented, in RIFRIF, in conformance with the serialization of the source according to an XML schema that MUST be specifiedimported in the RIF document.

An XML schema can also be combined with a RIF document without withoutthe associated data source being specified: in that case, the selection of the data source to be combined with the RIF document is left to the RIF document consumer. This provides a way to communicate the data model that is intended, in a RIF document, for the data sourcesource, without specifying an actual data source.

TBCEditor's Note: This section will be completed, e.g. with typical scenarios etc Data sources and schemasusage scenarios, in a future draft.


Importing XML data sources and schemas in RIF

In RIF, the Import directive is used to communicate the location of an external document to be combined with the RIF document that contains the directive and, optionally, a profile that governs the combination.

ThisIn [RIF-Core], [RIF-PRD] and [RIF-BLD], the use of the Import directive is limited to identifying an imported RIF document, or an RDF graph or an OWL ontology to be combined with a RIF document. An optional profile that governs the combination of a RIF document specifieswith an RDF graph or an OWL ontology can also be provided, as specified in [RIF-RDF-OWL].

This specification extends the Import directive in two ways:

  1. a new allowed value and a new set of allowable values are specified for the profile of an import:import, in addition to the values specified in [RIF-RDF-OWL]:
    • the new value is the URI: rif:xmlrif:xml-data;
    • in addition, any URI that identifies an XML schema document is allowed as a profile.
  2. the Import directive is further modified to makelocation sub-element, that contains the IRI ofthat identifies the imported data documentdocument, is made optional as well.

The BNF-style pseudo-schema for the modified syntax is as follows: 

    <Import>
       <location> xs:anyURI </location>?
       <profile> xs:anyURI </profile>?
    </Import>

The following constraints must be satisfied:

This specification does not prescribe the behaviour of a conformant implementation when one of the above constraint is not satisfied.

Available documentsThis is a mapping of strings onto document nodes. The string representspecification does not prescribe the absolute URIbehaviour of a resource. The document node is the root ofcomformant implementation when an Import directive contains a treeprofile that represents the resource using using the XQuery 1.0 and XPath 2.0 Datais neither rif:xml-data, nor an URI that identifies an XML schema.

A simple data model . In RIF, the availablefor XML documents

in the dynamic context, whenThe rules retrieved from a RIF document are used in combination withdata sources, is defined as follows: if the RIF document contains Import directives wheremodel described in this section specifies the profileinformation that is rif:xml , the location URIaccessible in each of these directives is mapped onto the document nodean XML document, possibly in combination with an XML schema, and that is used to specify the rootinterpretation of the tree that represent theRIF condition language with respect to an XML instance document identified by that location URI using the data model , wheredocument.

The data model is constructed directly if the XML instance document does not declarea schema-location URI; orstripped down version of the XQuery 1.0 and XPath 2.0 Data Model is constructed from the post-schema validation infoset (PSVI), if the XML instance document declares schema-location URI; if[XDM]. As a consequence, the RIF document contains Import directives that locatecondition language can be considered a partial implementation of the XQuery 1.0 and XPath 2.0 Data source documentModel, and where the profile is an URI that identifies an XML schema,the location URI in eachinterpretation of these directives is mapped ontothe document node that is the rootRIF condition language with respect to XML documents can be specified in terms of the tree that represent the XML instanceXQuery 1.0 and XPath 2.0 Data Model or its implementations, such as XPath 2.0 [XPath 2.0]. This document identified by that location URI usingwill reuse definitions from the XQuery 1.0 and XPath 2.0 Data Model ,and the XPath 2.0 specifications, as appropriate, and otherwise provide pointers and examples where relevant.

Definitions

The data model is constructedspecifies the information items from the post-schema validationXML infoset (PSVI) created using the XML schema identified by[Infoset] and from the profile; Editor's Note:post-schema validation infoset (PSVI), or derived from the data model supports incompletely validated documents. Elementsinfoset and attributesthe PSVI, that are not valid are treated as having unkonw types. Seerequired to interpret some RIF constructs with respect to an XML instance document.

Definition (Information item). (from [ Section 3.3 Construction from a PSVI XDM ]. Editor's Note: IfInfoset]) An imported data source documentinformation item is notan abstract description of some part of an XML instancedocument: each information item has a set of associated named properties.  ☐

In this document, its representation using the data modelan information item is builtsaid to be constructed from the valid XML serialization ofan infoset, if the data source according to the XML schemaitem that it describes is identified in the profile.contained in addition, the URI of anya data source that is dynamicallynot associated at run timewith the rules retrieved from the RIF document, is mapped onto the document node thatan XML schema when it is the root of the tree that represents the dynamically associated data source using the data modelimported in RIF. If the RIF document contains an Import directive where the location of thedata source document is missing and the profileis an URI that identifiesassociated with an XML schema, all the data model is constructed frominformation items used to describe the post-schema validation infoset (PSVI) created usingcontent of that XML schema; else, thedata model issource are said to be constructed directly. Editor's Note: Iffrom a dynamically associated data sourcePSVI.

If an information item is notconstructed from an XML instance document, its representation usinginfoset, all general and external parsed entities must be fully expanded before the data model is built fromconstructed.

In this specification, the valid XML serialization ofproperty names are shown in square brackets, [thus].

The data source according tomodel relies on three types of information items:

Given a data source, the relevant set of information items may be created by methods other than parsing and/or schema-validating an XML document. This specification does not contains an Import directive that identifiesdescribe or prescribe any method for retrieving the required information from a data source, possibly combined with an XML schema inschema.

This specification distinguishes between the profile, without associating it to an importeddata source document withmodel as a general concept and specific items (information items or atomic values) that are concrete examples of the location , the direct constructiondata model. Some concrete examples are being particularly distinguished by being identified as instances of the data model is implementation dependent, but stable (that is, the same document produces always.

Definition (Instance of the samedata model instance). There are no constraint on howmodel). An instanceinstances of the data model may be constructed directly, save thatis a sequence of element information items, in document order. In particular, given an XML document D, the resultinginstance must satisfy allof the constraints described in the XQuery 1.0 and XPath 2.0data model specificationthat are relevant to the partial implementation of the specification in RIF. Available collections The default available collection in the dynamic context, as returned by a call to fn:collection with no argument (see [ Section 15.5.8 XFO ]),describes D is the sequence of all the nodes of typeelement information items that describe an element contained in D, in document order.  ☐

When there is no ambiguity with respect to D, the setinstance of the treesdata model that representdescribes D will be called, simply: the available data sources documents usinginstance of the XQuery 1.0 and XPath 2.0data model , as specified.

Definition (Atomic value). An atomic value is a value in the previous section . This document does not specifyvalue space of an atomic type and is labeled with the function fn:collection further. RIF as a partial implementation of XDM This document specifies, for some constructsname of the RIF condition language,that atomic type.  ☐

Definition (Atomic type). An interpretation with respect to the available data source documents represented using the XQuery 1.0 and XPath 2.0 Data Model , as described above.atomic type is one of the specification provides, therefore,20 primitive simple types defined in Section 3.3 Primitive Datatypes of [XSD 1.1 Part 2] or a mean to combine RIF documents with XML data sources, withtype derived by restriction from another atomic type.  ☐

Types derived by list or withoutunion are not atomic.

Definition (Sequence). A sequence is an associated XML schema, as well asordered collection of zero or more information items.  ☐

A mechanism to associate withsequence cannot be a RIF document,member of a sequence. An important characteristic of the data model intended for the data sources asis that there is no distinction between an XML schema. This makes RIFitem (a information item or an implementation of the XQuery 1.0atomic value) and XPath 2.0 Data Modela singleton sequence containing that item. An item is equivalent to a singleton sequence containing that item and vice versa.

Except when specified otherwise, sequences are ordered according to the document order.

However, RIFDefinition (Document order). A document order is onlydefined among all the element information items that describe a very partial implementationgiven XML instance document. Document order is a total ordering. Informally, document order is the order in which nodes appear in the XML serialization of a document.  ☐

Within a tree, document order satisfies the data model : it makes use onlyfollowing constraints:

  1. The root node is the first node.
  2. Every node occurs before all of someits children and descendants.
  3. The relative order of siblings is the propertiesorder in which they occur in the children property of elementtheir parent node.
  4. Children and descendants occur before following siblings.

XML element, attribute nodes,and type names are usually represented as definedXML qualified names, or QNames. However, xs:QName is not a RIF-Core built-in datatype. In the data modelmodel, all qualified names, including atomic values, are represented as expanded QNames.

Variables For the purposeDefinition (Expanded QName). An expanded QName is a pair of interpreting RIF constructs with respect to the available data source documents represented using the XQuery 1.0two values, consisting of a possibly empty namespace URI and XPath 2.0 Data Model ,a local name.  ☐

Element information items

There is an element information item for each element appearing in the domainXML document. One of the variables must include allelement information items corresponds to the nodes inroot of the default available collection . Class identifiers Class identifiers in RIF class membershipelement tree, and subclass relationship formulas, representedall other element information items are accessible by recursively following its [children] property.

An element information item has the Member and the Subclass construct, respectively, can be interpreted with respect to the available data source documents represented usingfollowing properties:

  1. [namespace name] The XQuery 1.0 and XPath 2.0 Data Model , as identifying subsetsnamespace name, if any, of the element nodes intype. If the default available collection : a class identifier that is represented byelement does not belong to a RIF constant of type rif:iri identifiesnamespace, this property has no value.
  2. [local name] The setlocal part of allthe element nodeselement-type name. This does not include any namespace prefix or following colon;
  3. [children] An ordered list of child information items, in document order. This list contains only element information items and character information items, one for each element and data character appearing immediately within the default available collectioncurrent element. It does not contain other kinds of information items, such that:as attribute information items, even if the constant's value is an IRI where the local name has the form type(NAME) where NAME is either an IRI or anXML name from which an IRI can be obtainedelement described by casting into a QName and expandingthe QName, and,information item has attributes. If the identiferelement is a relative IRI that with onlyempty, this list has no members;
  4. [root] The element information item that describes the root element in the XML document. The [root] property all the element information items that describe elements contained in the same XML instance document point to the same root element information item, including that root element information item itself. If the [root] property of an element information item points to that element information item itself, the [root] properties of all the element information items that are accessible by following its [children] property, recursively, must point to that same root element information item;
  5. [attributes] An unordered set of attribute information items, one for each of the attributes of this element. This includes all of the "special" attributes (xml:lang, xml:space, xsi:type, etc.) but does not include namespace declarations (because they are not attributes). Default and fixed attributes, e.g. provided by XML Schema processing, are added to the [attributes]. If the element has no attributes, this set has no members;
  6. [type name] The [type name] property of an element information item is empty if, and only if, the element information item is constructed from an infoset. If the element information item is constructed from a PSVI, the type name is represented by an expanded QName. It is determined as described in Section 3.3.1.1. Element and Attribute Node Type Names from [XDM] (reproduced in APPENDIX TYPE NAME for the reader's convenience);
  7. [string value] The normalised representation of the content of the element as a string. The string value is calculated as follows:
    • If the element is empty or if it does not have any character information item children nor descendants, its string value is the zero length string;
    • Else, if the [type name] property of the element information item is empty, or if the element has a complex type with element-only content, or a complex type with mixed content, its string value is the string comprised of characters that correspond to the [character code] properties of each of the character information item children of the element and all its descendants, in document order. If the resulting string consists entirely of whitespace and the [element content whitespace] property of the character information items used to construct it are true, the string value is the zero-length string;
    • Else, if the element has a simple type or a complex type with simple content: its string value is the schema normalized value of the element;
    • Note that, if the element has a typed value, any valid lexical representation of the typed value can be used to determine the [string value] property;
  8. [typed value] The typed-value is calculated as follows:
    • If the element is empty or if it has element-only children, its typed value is the element itself; more precisely, if an element information item has no character information items in its [children] property, the value of its [typed value] property is the element information item itself. This is a deviation from the XQuery 1.0 and XPath 2.0 Data Model;
    • Else, if the [type name] property of the element information item is empty, or if the element has a complex type with mixed content (including xs:anyType), its typed value is the same as its string value;
    • Otherwise, the element must have a simple type or a complex type with simple content. Its typed value is computed as described in Section 3.3.1.2 Typed Value Determination, in [XDM] (reproduced in Appendix B for the reader's convenience). The result is a sequence of zero or more atomic values. The relationship between the values of the [type name], [typed value], and [string value] properties of an element information item is consistent with XML Schema validation. Note that in the case of xs:QNames and xs:NOTATIONs, the prefix is not preserved, and the typed values are represented as expanded QNames. This deviates from the [[#ref-xdm|XQuery 1.0 and XPath 2.0 Data Model];
  9. [is-id] If the [type name] property of an element information item is empty, or if the element has a complex type with element-only content, the [is-id] property is false. Else, if the typed value of the element consists of exactly one atomic value, that value is of type xs:ID, or a type derived from xs:ID, the [is-id] property is true, otherwise it is false.
  10. [is-idrefs] If the [type name] property of an element information item is empty, or if the element has a complex type with element-only content, the [is-idrefs] property is false. Else, if any of the atomic values in the typed-value of the element is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types, the [is-idrefs] property is true, otherwise it is false.

Attribute information items

There is an attribute information item for each attribute (specified or defaulted) of each element in the document, excluding those which are namespace declarations (because they are not attributes).

Attributes declared in the DTD with no default value and not specified in the element's start tag are not represented by attribute information items.

An attribute information item has the following properties:

  1. [namespace name] The namespace name, if any, of the attribute. Otherwise, this property has no value;
  2. [local name] The local part of the attribute name. This does not include any namespace prefix or following colon;
  3. [attribute type] An indication of the type declared for this attribute in the DTD. The only value that are relevant to this specification are ID, IDREF and IDREFS. If there is no declaration for the attribute or if no declaration has been read, this property has no value. The value of this property is not affected by the validity of the attribute value;
  4. [owner element] The element information item which contains this information item in its [attributes] property;
  5. [type name] Empty if the attribute information item is constructed from an infoset. If the attribute information item is constructed from a PSVI, the type name is represented as an expanded QName, and it is determined as described in Section 3.3.1.1. Element and Attribute Node Type Names from [XDM] (reproduced in Appendix B for the reader's convenience);
  6. [string value] The schema normalized value PSVI property if that exists; otherwise, the normalized attribute value according to Section 3.3.3 Attribute-Value Normalization in [XML]). Note that, if the attribute has a typed value, any valid lexical representation of the typed value can be used to determine the string value;
  7. [typed value] The typed-value is calculated as follows:
    • If the [type name] property of an attribute information item is empty, its typed value is the same as its string value;
    • Otherwise, a sequence of zero or more atomic values as described in Section 3.3.1.2 Typed Value Determination, in [XDM] (reproduced in Appendix B for the reader's convenience). The relationship between the values of the [type name], [typed value], and [string value] properties of an attribute information item is consistent with XML Schema validation.
  8. [is-id] If the attribute is named xml:id and its [attribute type] property does not have the value ID and its [type name] property does not have the value xs:ID, then [xml:id] processing is performed. This will assure that the value does have the type ID or xs:ID (if the attribute information item is constructed from an infoset or from a PSVI, respectively) and that it is properly normalized. The [is-id] property is always true for attributes named xml:id. Else, if the [attribute type] property has the value ID, or if the type name is xs:ID or a type derived from xs:ID, the [is-id] property is true; otherwise, it is false. This specicification does not prescribe the behaviour of a RIF consumer application if an error is encountered during [xml:id] processing.
  9. [is-idrefs] True if the value of the [attribue type] property is IDREF or IDREFS, or if any of the atomic values in the typed-value of the attribute is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types. Otherwise, false.

Character information items

There is a character information item for each data character that appears in the document, whether literally, as a character reference, or within a CDATA section.

Each character is a logically separate information item, but applications are free to chunk characters into larger groups as necessary or desirable.

A character information item has the following properties:

  1. [character code] The ISO 10646 character code (in the range 0 to #x10FFFF, though not every value in this range is a legal XML character code) of the character.
  2. [element content whitespace] A boolean indicating whether the character is white space appearing within element content (see [XML], Section 2.10. White Space Handling). Note that validating XML processors are required to provide this information. If there is no declaration for the containing element, or if there are multiple declarations, or if no declaration has been read, this property has no value for white space characters. It is always false for characters that are not white space.

Resolution of references

Definition (Reference information item). Given an information item, I, whose [is-id] is true, and given an atomic value, id, of type ID, IDREF, xs:ID, or xs:IDREF, that matches one of the atomic values in I' s [typed value] property, the reference information item identified by id is the element information item, R, such that

Note that the reference information item is always an element.

Where this specification states, with respect to a set of information items, that the references are resolved, the following processing is applied to every information item in the set whose [id-refs] property is true:

No property value is changed in any information item: the references are resolved only on a "need-to-resolve" basis, where the specification of RIF as an implementation of the data model requires them to be resolved.

This specification does not prescribe a behavior if an error is encountered during reference resolution processing (such as IDREFs without corresponding IDs, invalid or duplicate ID, etc).

Example of a data model instance

Consider the following XML instance document, representing data about customers, that can be retrieved from the IRI: http://example.org/customertable/customers.xml: 

<CustomerTable xmlns="http://example.org/customertable"
               xmlns:xml="http://www.w3.org/XML/1998/namespace">
  <Customer xml:lang="en">
    <Name> John </Name>
    <Account> 111 </Account>
  </Customer>
  <Customer xml:lang="fr">
    <Name> Jane </Name>
    <Account> 222 </Account>
    <Id> 222 </Id>
  </Customer>
</CustomerTable>

Consider, further, the following XML schema, available from http://example.org/customertable/customers.xsd: 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:xml="http://www.w3.org/XML/1998/namespace"
           targetNamespace="http://example.org/customertable">  

  <xs:element name="Name" type="xs:string"/>
  <xs:element name="Account" type="xs:integer"/>
  <xs:element name="Id" type="xs:integer"/>
  
  <xs:element name="Customer">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="Name"/>
        <xs:element ref="Account"/>
        <xs:element ref="Id" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
    <xs:attribute ref="xml:lang"/>
  </xs:element>

  <xs:element name="CustomerTable">
    <xs:complexType>
      <xs:all>
        <xs:element ref="Customer" minOccurs="0"/>
      </xs:all>
    </xs:complexType>
  </xs:element>

</xs:schema>

The instance of the data model that describes the XML document associated with the schema, is a sequence that contains the following eight element information items, in that order:

  1. an element information item representing the CustomerTable element, with the following values for its properties
    • [namespace name]: http://example.org/customertable
    • [local name]: CustomersTable
    • [children]: a sequence of two element information items, which are the two Customer element information items in the data model instance, in the same order; that is, items 2 and 5 in the data model instance, in that order;
    • [root]: the element information item itself;
    • [attributes]: empty;
    • [type name]: http://example.org/customertable "some locally unique identifier for the anonymous type of the CustomerTable element"
    • [string value]: "John 111 Jane 222 222"
    • [typed value]: the element information item itself;
    • [is-id]: false;
    • [is-idrefs]:false;
  2. an element information item that describes the first Customer element in the document, with the following values for its properties
    • [namespace name]: http://example.org/customertable
    • [local name]: Customer
    • [children]: a sequence of two element information items, which are items 3 and 4 in the data model instance, describing the Name and Account sub-elements, respectively, in that same order;
    • [root]: same value as the [root] property of the previous element information item;
    • [attributes]: a attribute information item representing the xml:lang attribute. The attribute information item has the following values for its attributes:
    • [type name]: http://example.org/customertable "some locally unique identifier for the anonymous type Customer"
    • [string value]: "John 111"
    • [typed value]: the element information item itself;
    • [is-id]: false;
    • [is-idrefs]:false;
  3. an element information item representing the Name sub-element of the first Customer element in the document, with the following values for its properties
    • [namespace name]: http://example.org/customertable
    • [local name]: Name
    • [children]: a sequence of four character information items, spelling j o h n, in that order;
    • [root]: same value as the [root] property of the previous element information item;
    • [attributes]: empty;
    • [type name]: http://www.w3.org/2001/XMLSchema string
    • [string value]: "John"
    • [typed value]: "John"
    • [is-id]: false;
    • [is-idrefs]:false;
  4. an element information item representing the Account sub-element of the first Customer element in the document, with the following values for its properties
    • [namespace name]: http://example.org/customertable
    • [local name]: Account
    • [children]: a sequence of three character information items, spelling 1 1 1, in that order;
    • [root]: same value as the [root] property of the previous element information item;
    • [attributes]: empty;
    • [type name]: http://www.w3.org/2001/XMLSchema integer
    • [string value]: "111"
    • [typed value]: 111
    • [is-id]: false;
    • [is-idrefs]:false;
  5. an element information item that describes the second Customer element in the document;
  6. an element information item representing the Name sub-element of the second Customer element in the document;
  7. an element information item representing the Account sub-element of the second Customer element in the document;
  8. an element information item representing the Id sub-element of the second Customer element in the document;

RIF as an implementation of the data model

This section specifies, for some constructs of the RIF condition language, an interpretation with respect to the instances of the above data model that represent the imported data sources.

The specification provides, therefore, a means to combine RIF documents with XML data sources, with or without an associated XML schema, as well as a mechanism to associate with a RIF document, the data model that is assumed, in the interchanged rules, for the data sources, in the form of an XML schema (or a set of XML schemas).

Constants

Any constant in a RIF document can be interpreted with respect to atomic values in a data model instance. Some RIF constant, those with a DM-Name, can also be interpreted with respect to the expanded QNames that represent element, attribute and type names in a data model instance.

DM-Names

The data model relies on expanded-QNames to represent qualified names. However, RIF-Core has no built-in datatype for qualified names. In order to specify the interpretation of RIF constructs with respect to data model instances that describe imported data sources, we define a mapping, DM-Names, from xs:string constants to expanded QNames, and we use that mapping to define the DM-Name of constants.

Definition (DM-Names). DM-Names is a mapping from xs:string constants to expanded QNames. An xs:string constant of the form [URI '#']? NAME is mapped to an expanded QName where the optional URI is the, possibly empty, namespace URI and NAME is the local name, if and only if 

NAME := [ xs:NCName | 'type(' xs:NCName ')' | 'list(' xs:NCName ')' | 'attribute(' xs:NCName ')']

For all the other xs:string constants, the mapping is undefined.   ☐

Definition (DM-Name). Given a RIF constant, c, of any type that can be cast into an xs:string, s, for which the DM-Names mapping is defined, the DM-Name of c is the expanded QName onto which DM-Names maps s. RIF constants that cannot be cast into an xs:string for which the DM-Names mapping is defined do not have a DM-Name.  ☐

By extension, given a constant, c for which a DM-Name is defined, we will write the namespace URI of c and the local name of c to refer to the namespace URI and local name components of c' s DM-Name, respectively.

Example 4.1.

  ☐

Class names

Constants that occur in a position where the identifier of a class is expected, e.g. in RIF class membership and subclass relationship formulas, can be interpreted as identifying subsets of the element information items in the instances of the data model that describe the imported data sources.

Given a constant, C, for which the DM-Name is defined, and an instance of the data model, IDM, let us call: C-set, the set that contains an element information item, N ∈ IDM, if and only if

This specification does not prescribe anything with respect to the interpretation as class identifiers, of constants for which the DM-Name is not defined.

Given an XML document, D, the sets of element information items selected by a constant C from the data model instance that describes D corresponds to the sequences of elements selected, in D, by the following XPath 2.0 expressions, where prefix is bound to URI:

  1. /descendant::element(*,[prefix:]NAME) if C has form [URI#]type(NAME);
  2. or /descendant::[prefix:]NAME (or /descendant::schema-element([prefix:]NAME) if the namespace is that of an in-scope schema definition), if C has form [URI#]NAME.

Example 4.2. With respect to the data model instance that describes the XML document from Section 3.6. Example of a data model instance, above, 

<Account>111</Account>
<Account>222</Account>
<Id>222</Id>

<Name>John</Name>
<Name>Jane</Name>

☐

Slot names

Constants that occur in a position where a slot's name is expected, e.g. in RIF frame formulas, can be interpreted as identifying subsets of an element information item's [children] or [attributes] properties, in the instances of the data model that describe the imported data sources.

Given a frame o [ slot -> v ], where o identifies an element information item in a data model instance, and where slot is a RIF constant for which the DM-Name is defined, let us call: o/slot-sequence, the sequence constructed as follows, after references have been resolved:

Editor's Note: Shall we add a property that contains the expanded QNames of the relevant substitution groups' heads in the element information item part of the data model?

This specification does not prescribe anything with respect to the interpretation of slot names for which the DM-Name is not defined.

Given a XML instance element, E, the element information item that describes it in a data model instance, e, and a constant, C, for which the DM-Name is defined, the sequence of information items selected from e by a constant C, that is, the e/C-sequence as defined above, corresponds, in the absence of references, to the sequences of nodes selected by the following XPath 2.0 expressions, where prefix, if present, is bound to URI, and where the context element is E:

  1. attribute::[prefix:]NAME, if the, optional, namespace URI in C' s DM-Name is URI and if the local name has the form attribute(NAME);
  2. child::[prefix:]NAME, resp. child::schema-element([prefix:]NAME), if the, optional, namespace URI in C' s DM-Name is URI and if the local name is NAME.

Example 4.3. In the context of the data model instance that describes the XML document from Section 3.6. Example of a data model instance, above, consider a RIF frame expression of the form o[slot->v]:

Notice that, in this example, the o/slot-sequences remain unchanged in the schema-less case introduced in example 4.2: indeed, there are no substitution groups involved.  ☐

Variables

For the purpose of interpreting RIF constructs that occur in a RIF document, D, with respect to the imported data sources, the domain of all the variables declared in D must include, at least:

One way to guarantee that this requirement is satisfied is to embed the imported data sources as RIF facts in D, as specified (non-normatively) in the Appendix C: Embedding imported data sources as RIF facts.

Class membership: rif:Member

A class membership atom, o # C, where C stands for a RIF constant whose DM-Name is defined, is true if o identifies one of the element information items in the C-set constructed from the union of the imported data model instances.

Example 4.4. Continuing with the example XML instance document from Section 3.6, and the data model instance that describes it, and assuming that the following RIF class membership atoms occur in a RIF document that imports the XML document, associated with the XML schema from the example:

☐

Sub-class relationship: rif:Subclass

A sub-class relationship atom, s ## C, where s and C stand for RIF constants whose DM-Name are defined, is true if, the s-set is a subset of the C-set for any given instance of the data model.

Note that the sub-class relationship atom is defined in RIF-BLD and RIF-PRD only, not in RIF-Core.

Example 4.5. Assuming that the following RIF subclass relationship atoms occur in a RIF document that imports the XML document from the example in Section 3.6: 

<Subclass>
   <sub>
     <Const type="xs:string">http://example.org/customertable#Account</Const>
   </sub>
   <super>
     <Const type="rif:iri">http://www.w3.org/2001/XMLSchema#type(integer)</Const>
   </super>
</Subclass>

 <Subclass>
   <sub>
     <Const type="xs:string">http://www.w3.org/2001/XMLSchema#type(integer)</Const>
   </sub>
   <super>
     <Const type="rif:iri">http://www.w3.org/2001/XMLSchema#type(string)</Const>
   </super>
</Subclass>

☐

Frames: rif:Frame

A frame o [ slot -> v ], where o identifies an element information item in an imported data model instance, and where v identifies a constant whose DM-Name is defined, is true

Example 4.6. Continuing with the previous example:

Editor's Note: The typed-value, in the schema-less case, is the string-value, that is, a string. So, the xs:integer 111 is not equal to the typed-value of the Account node. But it seems reasonable to keep the equality, in the schema-less case, because the type of the RIF constant gives a hint about the intended data model to the consumer. If we agree on this, should it be made explicit in the interpretation of frames?

Example 4.7. Consider the following element with a mixed-content: 

<letterBody>
  Thank you for ordering the <item>widget</item>.
  It should arrive by <arrivalDate>09-09-09</arrivalDate>
</letterBody>

Assume that the element is contained in a data source that is imported in a RIF document, and assume that the RIF variable ?v, occurring in that RIF document, is bound to an element information item that describes, in the data model instance, the parent element of the above letterBody element.

The value of the frame ?x["letterBody"->?y] will be true is and only if ?y is bound to a string constant that contains the following text: "Thank you for ordering the Widget. It should arrive by 09-09-09"; that is, the string value of the information item that describes the letterBody element.

Indeed, if an element has a complex type with mixed content (including xs:anyType), its typed value is its string value.   ☐

Atoms: rif:Atom

An atom, P(a1 ... n), n ≥ 0, where P stands for a RIF constant whose DM-Name is defined, is true if there is, at least, one element information item, e, in the P-set constructed from the union of the imported data model instances, such that

Editor's Note: Is that one useful? If we decide to keep it, it needs some more work. E.g., dealing with missing children elements (when minOccur = 0); dealing with the fact that P can occur both in the position of a class identifier in a membership or subclass relationship formula, or as the name of a relation in an atom; etc.

A atom with named arguments, P((name1 a1) ... (namen n)), n ≥ 0, where P stands for a RIF constant whose DM-Name is defined and each of the namei are RIF names whose DM-Name is defined, is true if there is, at least, one element information item, e, in the P-set, such that

Note that the order in which the (namei ai) pairs occur does not affect the truth value of the atom.

Note that atoms with named aruments are defined only in RIF-BLD, not in RIF-Core nor in RIF-PRD.

Editor's Note: If that is deemed useful, it needs some more work, e.g. extending the definition of DM-Name to RIF names, dealing with P occurring both in the position of a class identifier in a membership or subclass relationship formula, and as the name of a relation in an atom; etc.

Example 4.8. TBC

Conformance

Editor's Note: This section will be completed in a future draft.

The special case of RDF and OWL data sources

Editor's Note: RDF an dOWL data sources can be imported in RIF documents in two different ways: according to the RIF-RDF-OWL specification, that specifies the combination of RIF documents with RDF and OWL graphs, directly; or as XML document. This section examines how this two ways of importing RDF and OWL documents relate. The section will be completed in a future draft.

References

[DTD]
REF DTD tbd

[Infoset]
XML Information Set (Second Edition), John Cowan and Richard Tobin, Editors. World Wide Web Consortium, 04 Feb 2004. This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204. The latest version is available at http://www.w3.org/TR/xml-infoset.

[RIF-Core]
REF Core tbd

[RIF-BLD]
REF BLD tbd

[RIF-PRD]
REF PRD tbd

[RIF-RDF-OWL]
REF SWC tbd

[XF&O]
REF XF&O tbd

[XML-SCHEMA]
REF XML-S tbd

[XMLS-2]
REF XML-S part 2 tbd

[XPATH 2.0]
REF XPath 2.0 tbd

Appendix A: Glossary (non-normative)

Editor's Note: This section will be completed in a future draft.

Appendix B: Extract from the local part:XQuery 1.0 and XPath 2.0 Data Model (non-normative)

Element and attribute node type names (from [XDM])

Editor's Note: This section reproduces the settext of all the nodesSection 3.3.1.1. Element and Attribute Node Type Names in [XDM], for the default available collection whose type-name matchesreader's convenience. Notice that, for the NAME IRI (orpurpose of this specification, the IRI obtained fromtype name ), if it is absolute, or the absolute IRI built from the node's default namespace, if thereis one,considered unknown, and the NAME (or[type name] property is left empty, when the IRI obtained from NAME ), if it[validaty] property does not exist or is not; or, if"unknown" and the identifier[validation attempted] property does not exist or is an absolute IRI:"none".

The subsetprecise definition of the above, such that the namespace partschema type of the identifer matches the namespace part in the node's node-name; else, if the constant's value isan absolute IRI:element or attribute information item depends on the setproperties of allthe nodesPSVI. In the default available collection, such that that absolute IRI matches the node's node-namePSVI, [Schema Part 1] defines a [type definition] property as well as an expanded QName. If the namespace in the IRI is the target namespace of an in-scope schema definition,the set[type definition namespace], [type definition name] and [type definition anonymous] properties, which are effectively short-cut terms for properties of element nodes that it identifies contains alsothe nodes that representtype definition. Further, the [element declaration] and [attribute declaration] properties are defined for elements that belong to a substitution group where the head element's name matches the local part in the IRI,and that occurattributes, respectively. These declarations in a position whereturn will identify the schema requires[type definition] declared for the head element; else, ifelement or attribute. To distinguish the constant's value is a relative IRI:[type definition] given in the set of allPSVI for the nodes inelement or attribute instance from the default available collection, such that Either[type definition] associated with the node has a default namespace in its scope, anddeclaration, the relative IRIformer is referred to below as the local name of the element. Ifactual type and the default namespace islatter as the target namespacedeclared type of an in-scope schema definition,the set ofelement nodes contains alsoor attribute instance in question.

The nodes that representtype depends on the elements that belong to a substitution group wheredeclared type, the head element's name matchesactual type, and the relative IRI,[validity] and that occur[validation attempted] properties in a position wherethe schema requires the head element; orPSVI. If:

The node identified by o , that contains onlyprefix associated with the node whose node-name matchestype names is implementation-dependent.

Typed value determination (from [XDM])

This section describes how the IRI (possibly completed with namespaces etc) TBC ; else, if slottyped value of an Element or Attribute Node is computed from an element or attribute PSVI information item, where the information item has either a constant ofsimple type rif:iri ,or can be cast intoa constant ofcomplex type rif:iri ,with simple content. [...]

The slot -sequencetyped value of Attribute Nodes and some Element Nodes is a sequence of atomic values. The subsettypes of the element nodesitems in the children propertytyped value of a node may differ from the type of the elementnode identified by o , whose node-name matchesitself. This section describes how the IRI (possibly completed if it istyped value of a relative IRI, see class identifiers, above; and including nodes representing elements in the substitution group, as appropriate) TBC ; else, if slotnode is a constantderived from the properties of type xs:string whose value isan XML name, the slot -sequence isinformation item in a PSVI.

The same settypes of element nodesthe items in the children propertytyped value of the elementa node identified by o ,are determined as iffollows. The slot name wasprocess begins with T, the IRI obtained by castingschema type of the node itself, as represented in the PSVI. For each primitive or ordinary simple type T, the W3C XML name intoSchema specification defines a QName and expanding the QName. Editor's Note: Multiple sub-elements withfunction M mapping the same name are different values, since frames are multi-valued.lexical representation of a value onto the value of an object-oriented object.attribute term (or whateveritself.

Note. For atomic and list types, the notation) would bemapping is the list containing“lexical mapping” defined for T in [Schema Part 2]; for union types, the attribute -sequence asmapping is the lexical mapping defined above, preservingin [Schema Part 2] modified as appropriate by any applicable rules in [Schema Part 1]. The document-order .mapping, so modified, is a function (in the interpretation, with respectmathematical sense) which maps to a single value even in cases where the available data source documents represented using the data model , of frames whose slot names do not fall into one oflexical mapping proper maps to multiple values.

The above categoriestyped value is implementation dependent. NB: the binding of prefixes to namespaces, when expanding QNames, comes fromdetermined as follows:

The slot sequences correspondtyped value determination process is guaranteed to the sequences selected, respectively, by the XPath 2.0 expressionsresult in a sequence of atomic values, each having a well-defined atomic type. This sequence of atomic values, in turn, determines the form: attribute:: QNAME , for slot names where the local part hastyped-value property of the form attribute(QNAME) ; child:: QNAME , resp. child::schema-element( QNAME ) otherwise. Examples. TBC Conformance TBCnode in the special case of RDF and OWLdata sources TBC References [DTD] REF DTD tbd [RIF-Core] REF Core tbd [RIF-FLD] REF FLD tbd [RIF-PRD] REF PRD tbd [RIF-RDF-OWL] REF SWC tbd [XF&O] REF XF&O tbd [XML-SCHEMA] REF XML-S tbd [XMLS-2] REF XML-S part 2 tbd [XPATH 2.0] REF XPath 2.0 tbd Appendix A: Glossay TBCmodel.

Appendix B: Example TBCC: Embedding imported data sources as RIF facts (non-normative)

Editor's Note: This section will be completed in a future draft.