SADiC: The Semantic API for the Delivery Context

The SADiC Semantic Approach

Francesco Cannistrà,
fracan@inwind.it

 

 

SADiC is a Java API for the processing, the validation and the interrogation of delivery context information that is available by means of CC/PP  and/or UAProf  profiles. This paper provides a brief overview of the features of SADiC and presents its semantic approach.

 

Contents:

Motivations and Background
1. Overview of the Features of SADiC
2. The Semantic Approach of SADiC
3. Defining a Domain
4. Managing Multiple Versions of the Same Vocabulary
5. Leveraging the Extension Vocabulary
6. Conclusions
Appendix A: the Basic Abstract Ontology (and the Extension Vocabulary)
References

 

 

Motivations and Background 

The term delivery context [4] is used to indicate the set of attributes or parameters that characterize a client environment  and that can influence the way a user leveraging this environment accesses and/or enjoys and/or perceives the contents provided by a Web server. The delivery context information should be exploited by the servers to select and/or to adapt contents and their formats in the perspective of delivering data that meet the requirements of the specific fruition context of each client. In fact, in the scenario of a Web populated by a wide variety of user-end devices - possibly connected to the Internet through different network access channels - the users’ expectation to access the Web pervasively (regardless of the characteristics of the device leveraged from time to time) is fostering the service providers and content authors to engage issues regarding the device independent provision of information content [3,4]. Since the capabilities of terminals and their equipments (and either of the network they are picked up to) are heterogeneous and dynamically changing, contents formatted for optimal fruition within certain access/presentation environments (e.g. desktop computers connected to the Internet through wide-band channels) cannot be suitable for other contexts too (e.g. mobile phones accessing the Internet through a wireless network). 
Therefore, in order to address the device independence issues over the Web [3,4], the research community is investigating , above all, two main aspects:

The Composite Capability/Preference Profiles (CC/PP) [11, 12, 13]and the related User Agent Profile (UAProf) [15, 16, 17] are two parallel specifications that aim at defining a standard for representing delivery context information,  and they are both still being developed: the CC/PP by the World Wide Web Consortium (W3C) [2] and the UAProf by the Open Mobile Alliance (OMA, formerly the WAP Forum) [14]. Both the standards are based on the W3C Resource Description Framework (RDF) [6, 7, 8, 9, 10] and the eXtensible Markup Language (XML) [5], the two lingua franca upon which will be founded the future generation of the Web: the Semantic Web [18]. 

The Semantic API for the Delivery Context (SADiC) [1] is an innovative  Java API for processing and interrogating CC/PP and UAProf profiles, which exploits the philosophy of the Semantic Web.  

Top

1. Overview of the Features of SADiC

SADiC [1] is a Java API for processing the delivery context information expressed by means of CC/PP [11, 12, 13] or UAProf [15, 16, 17] profiles. It exposes a set of rich programming interfaces to access all the information conveyed by a profile basing on different criteria.

SADiC is able to handle profiles that reference multiple vocabularies and to perform the profile resolution process, i.e., to merge together multiple profiles acting as segments that compose an overall logical profile. However, as regards the profile resolution, SADiC does not rely on any specific communication mechanism that could be leveraged to transport a profile. This way SADiC is completely protocol-independent and is suitable for deployment and use in every application environment based on the Java technologies. For this purpose, even some utility classes are provided that implement a generic protocol manager and provide the primitives to implement whatever specific protocol handler that could leverage the native communication facilities provided by whatever specific Java-based  platform. 

For example, SADiC already provides two protocol handlers for use within a J2EE Web Tier, corresponding, respectively, to the CC/PP Exchange Protocol over HTTP (CC/PP ex) and the UAProf extension of the Wireless Profiled HTTP (W-HTTP). Further more, SADiC already provides the implementation of a simple Servlet Filter that leverages these handlers (by means of the protocol manager) in order to extract the CC/PP profiles communicated through an HTTP mechanism and to provide seamlessly  with the already processed profile the servlets or filters following in the processing chain of an HTTP request. 

SADiC is either general and extensible. Its processing model takes into account all the aspects involved in the processing of a CC/PP profile and executes each single general operation (e.g., profile resolution or validation of profile components and attributes) in the specific semantic context of each vocabulary referenced by the profile currently being processed. This way, no any vocabulary-specific information is hard-coded in the skeleton of the processing model and the vocabulary-customized processing is performed dynamically and seamlessly. 

The set of recognized vocabularies is not fixed and can be extended at every time. Further more, the API provides simple extension facilities that can be exploited by developers to implement new processing semantics for new vocabularies and to have these semantics applied seamlessly for profiles that reference these vocabularies (without the need of any further action). However, SADiC is not tied to any vocabulary: even for unknown vocabularies, the processing of profiles is executed consistently by applying a default behavior when performing the profile resolution and by providing a basic string-based access to data.   

One of the major features of SADiC is its ability to comply dynamically with both the CC/PP and UAProf, and to overcome their cross-interoperability problems within a purely semantic context. This paper focuses principally on this aspect and shows how through the semantic approach of SADiC it is possible to achieve semantic convergence between CC/PP and UAProf at an RDF level.  

Top

2. The Semantic Approach of SADiC  

The semantic approach of SADiC leverages the notion of ontology  [19, 22] in order to achieve semantic convergence between the CC/PP and UAProf specifications. This approach also allows to overcome other problems actually affecting the practical use of CC/PP and UAProf, like the managing of backword compatibility between subsequent vocabulary versions or of the equivalence of multiple namespaces to refer to the same logical vocabulary. This way, SADiC proposes itself as one of the first practical use cases and instance implementations of the Semantic Web [18] philosophy and concepts.

An ontology is a collection of definitions that describe computer-usable concepts (and either introduce the vocabulary of terms that rely on them) in the perspective of representing a domain, i.e., an area of knowledge, for machine-understanding purposes. The knowledge encoded by an ontology can also be imported and reused by other domains. This way, it is possible to build complex domains that grow each over each other and that represent different levels of abstraction of the same knowledge base, possibly specializing and/or extending and/or enhancing this for a particular application purpose. 

SADiC leverages this basic idea to manage vocabularies and to achieve, within a purely semantic context, the cross-interoperability just promised but not yet reached by the CC/PP and UAProf specifications.

The API relies on a basic ontology that acts as a general and abstract knowledge base introducing all the basic CC/PP concepts [12]. E.g., the abstract concept of attribute property (i.e., the class of RFD properties that represent delivery context attributes), the abstract concepts of  structural properties (i.e., the component and defaults RDF properties that let instance the semantic structure of a profile within an RDF data model) and the concept of profile component (i.e., the Component class that acts as root component type for all profile components).
These concepts are associated with RDF terms defined by the ontology vocabulary and represent all the semantic elements needed to construct a CC/PP profile and to define a CC/PP attributes vocabulary. However, neither the structural domain introduced by this ontology, nor (above all) its lexical domain (i.e., the naming space) are intended to supersede the CC/PP structural vocabulary [12]. The ontology just represents the lowest level of abstraction of all CC/PP domains, which houses formally all the basic and shared semantic concepts already introduced by the CC/PP specification [12], not the terms that are to be used to leverage these concepts. 

An actual domain can import the basic concepts of the abstract ontology and map them to its own terms. Such a domain is intended as a  structural domain since it provides an effective naming space for the CC/PP semantic concepts and allows their leveraging through the specific terms it defines. Therefore, many lexically-different but semantically-equivalent domains can be introduced: these all exploit the same semantics of the CC/PP structural concepts, but allow to leverage them through different terms afferent to different namespaces. 

Consider, for example, the case of the structural vocabulary proposed by the CC/PP specification [12] and the vocabularies proposed by each version of the UAProf specification [15, 16, 17]. These vocabularies rely all on structural concepts that have exactly the same semantics but that are tied to terms defined within different naming spaces. Therefore, since a computer can recognize a concept only if this is associated (at least indirectly) with an unambiguous identifier, all these vocabularies should be considered incompatible each with each other. In fact, the basic idea of RDF [6, 7, 8, 9, 10] to provide a language to express machine-understandable facts is that a vocabulary [10], on the one hand, explicitly introduces unambiguous terms and either expresses the constraints on their use, and, on the other hand, implicitly identifies the semantics of the terms themselves, so that a machine, provided in advance with  the knowledge base of a vocabulary, can associate terms with concepts and resources, and, therefore, can deduce relationships and meanings.
With the semantic approach of SADiC the incongruities arising from the embodying of the terms that refer to the same semantic concepts within different (either changing) naming spaces are brilliantly solved. In fact, with the SADiC approach all the above vocabularies are associated with structural domains that just host suitable terms to refer to the shared semantics of the structural concepts, but that do not define the concepts themselves. Since these concepts are defined elsewhere (i.e., in the basic abstract ontology) and the different terms through which they can be referenced are formally mapped to them, the abovementioned semantic convergence and cross-interoperability are achieved automatically and rigorously.

At the leaf level of the SADiC semantic hierarchy there are the pure application domains, i.e., the domains corresponding to CC/PP vocabularies that define the attribute properties that can be used to declare the capabilities of a delivery context within a profile. These are defined through RDF schema vocabularies that reference and leverage the vocabulary associated with a well-known structural domain. 

Note that a structural domain can either be viewed as an application domain, since, further to introducing a naming space for the CC/PP structural concepts, it could also introduce a vocabulary of attributes (as in the case of UAProf) or suitable data types for the values of attributes (as in the case of the CC/PP specification). The only purely structural domain is represented by the base abstract domain, all others are treated as CC/PP application domains that could also act as structural domains (i.e., domains that map the shared semantics of the structural concepts to actual lexical spaces). 

In order for a domain to be a structural domain it should define, within its own naming space, at least a Component class (i.e., an RDF class acting as root component type for all profile components) and a component property (i.e., an RDF property acting as the structural property that provides the mechanism to declare the components of a profile).

Top

3. Defining a Domain

In order to define a domain that takes a place into the CC/PP semantic hierarchy, SADiC leverages the Web Ontology Language (OWL) [19, 20, 21, 22], the language for representing  ontologies on the Web. OWL is based on RDF and is still being developed by the W3C as a component of the Semantic Web Activity [18].

SADiC requires that only the structural domains are to be explicitly defined. The pure application domains (i.e., the domains that define vocabularies of attributes by leveraging the RDF vocabulary of an already existing structural domain) are created automatically by SADiC when the corresponding  RDF schema (i.e., the vocabulary) is parsed, after recognizing the proper structural domain that this extends (provided that such a structural domain is already installed into SADiC and is correctly leveraged).

To define a structural domain it is necessary to construct a simple OWL ontology [21] that expresses the basic facts that make of such a domain a semantic CC/PP structural domain. For this goal it is sufficient to state that the terms introduced by a RDF schema (within its own naming space) to refer to the semantics of the CC/PP structural elements  have the same intentional meaning of the concepts defined in the base abstract ontology (i.e., both RDF elements, even if identified by different terms, are semantically equivalent).

For example, the statements below show the basic OWL axioms required to introduce the domain corresponding to the structural vocabulary defined by the CC/PP specification:

  <owl:Ontology rdf:about="http://www.w3.org/2002/11/08-ccpp-schema">
    <owl:imports rdf:resource=
       "http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420" />
  </owl:Ontology>

  <owl:Class rdf:about="http://www.w3.org/2002/11/08-ccpp-schema#Component" >
    <owl:sameAs rdf:resource=
       "http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420#Component" />
  </owl:Class>

  <owl:Class rdf:about="http://www.w3.org/2002/11/08-ccpp-schema#Attribute" >
    <owl:sameAs rdf:resource=
       "http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420#Attribute" />
  </owl:Class>

  <rdf:Property rdf:about="http://www.w3.org/2002/11/08-ccpp-schema#component" >
    <owl:sameAs rdf:resource=
       "http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420#component" />
  </rdf:Property>

  <rdf:Property rdf:about="http://www.w3.org/2002/11/08-ccpp-schema#defaults" >
    <owl:sameAs rdf:resource=
       "http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420#defaults" />
  </rdf:Property>

  <rdf:Property rdf:about="http://www.w3.org/2002/11/08-ccpp-schema#Defaults" >
    <owl:sameAs rdf:resource=
       "http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420#defaults" />
  </rdf:Property>

It is important to emphasize that the domain ontology does not replicate - neither supersedes - the vocabulary corresponding to the original RDF schema. It just enriches the original schema without the need of modifying this and provides the machine-understandable representation of the knowledge required to assure of semantic interoperability. Neither new concepts, nor new terms are introduced: just only the already existing concepts and terms are referenced in order to construct the assertions that represent the intended semantic facts and only these facts. All other vocabulary information elements  are intended to be stored and retrieved from the original schema itself. For instance, the schema defined by the CC/PP specification, further to introducing the terms for referencing the structural concepts, defines four suitable data types for the attributes' values that can be leveraged for the definition of actual attribute properties by the CC/PP vocabularies that grow upon this structural domain. In the same way, in the case of an UAProf domain, the source that stores the vocabulary of attributes is the UAProf schema itself.

It is interesting to note also that the namespace URI of the OWL ontology that defines a domain could be whatever. In fact, the OWL ontology should start with  an ontology header  that in the case of the CC/PP domain outlined above would be like this:

  <owl:Ontology rdf:about="">
    <owl:sameAs rdf:resource="http://www.w3.org/2002/11/08-ccpp-schema" />
  </owl:Ontology>

What is important is that SADiC is able to locate such ontology. Actually SADiC retrieves the OWL ontologies representing the structural domains from the local file system of the machine that hosts it. However, in the future, scenarios that involve ontology servers could be suitable as well.

Top

4. Managing Multiple Versions of the Same Vocabulary

Further to the problems arising from the fact that the CC/PP and UAProf use different namespaces to refer to structural concepts that have the same semantics, another related problem that is actually impeding the use of these standards in wide-practice (and is interfering  with the implementation of cross-compliant processors) is that UAProf itself does not define an unambiguous namespace for its vocabulary.

At the moment there are three subsequent versions of the UAProf specification [15, 16, 17] and each one supersedes the older. In each version the vocabulary schema is completely redefined by replacing the definition of the vocabulary elements of the older version and possibly adding new elements (attribute properties or component types) or eliminating others. More important, each proposed vocabulary schema is tied to a new namespace URI.

Further more, even the namespace of the UAProf vocabulary proposed by each particular specification document is not unambiguously fixed. The former statement specification process of the OMA (at that time the WAP Forum) allowed that an already approved specification document could still change by means of a Specification Information Note (SIN). Provided with this, the WAP Forum probably did not follow the proper policy to update the UAProf specification since, each time a SIN made corrections to the vocabulary, it was changed also the namespace URI of the corresponding RDF schema. Therefore, as a matter of facts, we have attained a very confusing situation in which, even for a specific vocabulary tied to a specific specification document, there is not a unique namespace URI, but there are multiple namespaces that act as alias URIs to refer to the same logical UAProf vocabulary.

It is straightforward that the existence of multiple namespaces for the same logical vocabulary (either due to vocabulary multi-versioning and to the appearing of alias namespace URIs)  causes many problems and potential incongruities. In fact, processors that recognize a certain namespace are not able to handle profiles that reference the same vocabulary through another namespace URI and therefore the risk for both profiles and processors not to be widely compliant or to became suddenly meaningless is more than concrete.

In the development of SADiC all these problems have been considered and solved. In fact, SADiC is able to handle the vocabularies semantic equivalence either in the case of existence of different versions of the same vocabulary and in the case of  multiple namespace URIs that refer to a same logical vocabulary. For this purpose it is sufficient to add some simple ontology headers when a domain is specified. 

Consider, for example, the domain corresponding to the second version of the UAProf specification. The table below shows the complete OWL ontology associated with this domain:

<?xml version="1.0"?>

<!-- *** SADiC: the Semantic API for the Delivery Context ***********
     *** Copyright (c) 2003 Francesco Cannistra'. All rights reserved.
     *** -->

<!DOCTYPE owl 
[ <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
  <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
  <!ENTITY owl "http://www.w3.org/2002/07/owl#" >
  <!ENTITY ccpp-abs "http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420" >
  <!ENTITY uaprof "http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430" >
  <!ENTITY uaprof-previous "http://www.wapforum.org/UAPROF/ccppschema-20000405" >
  <!ENTITY uaprof-alias-1 "http://www.wapforum.org/UAPROF/ccppschema-20010430" >
  <!ENTITY uaprof-alias-2 "http://www.wapforum.org/profiles/UAPROF/ccppschema-20020710" >
]>

<rdf:RDF
  xmlns          ="http://www.the-web-middle-earth.com/sadic/uaprof-domain-20010430#"
  xmlns:rdf      ="&rdf;"
  xmlns:rdfs     ="&rdfs;"
  xmlns:owl      ="&owl;"
  xmlns:ccpp-abs ="&ccpp-abs;#"
  xmlns:uaprof   ="&uaprof;#"
  xmlns:base     ="http://www.the-web-middle-earth.com/sadic/uaprof-domain-20010430">

  <owl:Ontology rdf:about="">
    <owl:sameAs rdf:resource="&uaprof;" />
  </owl:Ontology>

  <owl:Ontology rdf:about="&uaprof;">
    <owl:backwordCompatibleWith rdf:resource="&uaprof-previous;" />
    <owl:imports rdf:resource="&ccpp-abs;" />
  </owl:Ontology>

  <owl:Ontology rdf:about="&uaprof-alias-1;">
    <owl:backwordCompatibleWith rdf:resource="&uaprof;" />
    <owl:sameAs rdf:resource="&uaprof;" />
  </owl:Ontology>

  <owl:Ontology rdf:about="&uaprof-alias-2;">
    <owl:backwordCompatibleWith rdf:resource="&uaprof;" />
    <owl:sameAs rdf:resource="&uaprof;" />
  </owl:Ontology>

  <owl:Class rdf:about="&uaprof;#Component" >
    <owl:sameAs rdf:resource="&ccpp-abs;#Component" />
  </owl:Class>

  <rdf:Property rdf:about="&uaprof;#component" >
    <owl:sameAs rdf:resource="&ccpp-abs;#component" />
  </rdf:Property>

  <rdf:Property rdf:about="&uaprof;#defaults" >
    <owl:sameAs rdf:resource="&ccpp-abs;#defaults" />
  </rdf:Property>

</rdf:RDF>

Note that to assert that the actual domain  is the subsequent version of another domain (that one associated with the prior version of UAProf) it is sufficient to state that:

  <owl:Ontology rdf:about="&uaprof;">
    <owl:backwordCompatibleWith rdf:resource="&uaprof-previous;" />
  </owl:Ontology>

This also indicates that all the local terms tied to the previous namespace have the same intended interpretations in the naming space of the new version. 

Instead, to assert that the defined domain can also be referenced through a namespace URI different from the canonical namespace and that acts as an alias for this, there must be a  owl:backwordCompatibleWith and a owl:sameAs statements:

  <owl:Ontology rdf:about="&uaprof-alias-1;">
    <owl:backwordCompatibleWith rdf:resource="&uaprof;" />
    <owl:sameAs rdf:resource="&uaprof;" />
  </owl:Ontology>

Note again how the domain ontology does not affect neither supersedes the RDF schema containing the core vocabulary information.

Top

5. Leveraging the Extension Vocabulary

The SADiC base abstract ontology, further to defining the concepts that represent the pure intentional meaning of the CC/PP semantics, introduces an extension vocabulary that can be exploited in conjunction with whatever structural vocabulary in order to define a new vocabulary of attributes specifying completely its structural semantics. In fact, the CC/PP actually fails as regards two main aspects of the definition of an actual vocabulary of attributes [12]. 

The first aspect regards the specification of the complete data type for the range values of complex attributes. A complex attribute is an attribute whose values should be structured as a collection of simple data items, expressed, within a profile, through an RDF container (e.g. an rdf:Bag or an rdf:Seq). Actually, when the range of values of an attribute is declared to be structured as a container, it is not possible to specify also the data type for the elements that should compose the value of a thus structured type instance. This problem is a more general limitation of the RDF Schema language (RDFS) [10] itself and it is known as the long range problem. This consists in the inability of RDFS of providing formal means  to indicate, in the range constraints of a property, of what type should be the elements of a container that could be instanced as value of the property when such a property declares as range a container type.

The second aspect regards the indication of the resolution policy to be adopted when, while merging multiple profiles that act as segments of an whole logical profile (i.e., performing the profile resolution), collisions occur, i.e., multiple occurrences of the same attribute property are found in different segments with possibly different values. This issue is very important for the implementation and deployment of practical usage scenarios since an effective profile should be considered as a contextual entity that is composed and communicated dynamically, possibly by taking information pieces from different sources.

On its own behalf, UAProf has acknowledged the importance of the specification of this information in the definition of a vocabulary. But, since the suitable formal means to address this need have not been recognized  among the constructs provided by RDFS, this information has been specified, within the UAProf schemas, through comment fields for human-understanding purposes or through an improper use of the RDFS constructs [15, 16, 17].

As far as the long range problem is concerned, the extension vocabulary defines a RDF property, the longRange property, which can be used to enrich the range constraints of a generic RDF property that has range over a container type in order to assert of what RDF type should be the elements of a container instance that can be indicated as value of such a property. For example, a complex attribute whose values should be structured as a rdf:Bag of integer numbers could be defined (within a vocabulary of  attributes that leverages the structural domain of the CC/PP specification) as follows:

  <ccpp:Attribute rdf:ID="exampleAttribute">
    <rdfs:domain rdf:resource="http://www.w3.org/2002/11/08-ccpp-schema#Component" />
    <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" />
    <ext-voc:longRange rdf:resource="http://www.w3.org/2002/11/08-ccpp-schema#integer" />
  </ccpp:Attribute>

As regards the specification of the resolution policy for multi-segments composed profiles, the extension vocabulary introduces formally the concept of resolution rule by defining an RDF class, the ResolutionRule class, whose instances are RDF resources that identify unambiguously, through their URI references, specific behaviors to be adopted when, while performing profile resolution, multiple instances of the same attribute property occur in different profile segments for the same logical component of the equivalent profile. A defined resolution rule is to be associated with a vocabulary attribute through the resolution property provided by the extension vocabulary. The following example shows how a vocabulary could define a specific resolution rule - the Append rule - and could associate the correspondingly identified resolution behavior with the attribute of the previous example:

  <ext-voc:ResolutionRule rdf:ID="Append" />

  <ccpp:Attribute rdf:ID="exampleAttribute">
    <rdfs:domain rdf:resource="http://www.w3.org/2002/11/08-ccpp-schema#Component" />
    <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" />
    <ext-voc:longRange rdf:resource="http://www.w3.org/2002/11/08-ccpp-schema#integer" />
    <ext-voc:resolution rdf:resource="#Append" />
  </ccpp:Attribute>

More information about the semantic consistency of the extension vocabulary part of the CC/PP basic ontology can be found in the ontology itself provided in the Appendix A and in the inline comment fields there appended.

Top

6. Conclusions

This paper has introduced the semantic approach of SADiC, a Java API for processing and interrogating  CC/PP and UAProf profiles, and, in general, all RDF/XML formatted data that leverage a structural architecture that complies semantically with that one of the CC/PP. It was discussed how this approach is founded on the philosophy of the Semantic Web and in particular how it exploits the notion of ontology. In this way, SADiC is able to achieve rigorous semantic convergence between the CC/PP and UAProf and to avoid some cumbersome problems and incongruities arising, in general, from the proliferation of multiple namespace URIs to refer to the same logical vocabulary. Further more, the paper introduced briefly the extension vocabulary proposed by SADiC to address some important issues concerned with the specification of  the semantics of a CC/PP vocabulary.

The rich and flexible features provided by SADiC and its innovative semantic approach make of SADiC a general and extensible solution for developing delivery context-aware applications as a first step to achieve device independence.

Top

Appendix A: the Basic Abstract Ontology (and the Extension Vocabulary)

Below is given the entire OWL ontology representing the SADiC abstract knowledge base for CC/PP semantics, comprehending the extension vocabulary. The namespace URI of this ontology is:

  http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420

<?xml version="1.0"?>

<!-- *** SADiC: the Semantic API for the Delivery Context ***********
     *** Copyright (c) 2003 Francesco Cannistra'. All rights reserved.
     *** -->

<!DOCTYPE owl
[ <!ENTITY rdf      "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
  <!ENTITY rdfs     "http://www.w3.org/2000/01/rdf-schema#" >
  <!ENTITY owl      "http://www.w3.org/2002/07/owl#" >
  <!ENTITY ccpp-abs "http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420#" >
]>

<rdf:RDF  xmlns="http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420#"
  xmlns:rdf ="&rdf;"
  xmlns:rdfs="&rdfs;"
  xmlns:owl ="&owl;"
  xmlns:base="http://www.the-web-middle-earth.com/sadic/ccpp-abstract-domain-ontology-20030420">

  <owl:Ontology rdf:about="">
    <rdfs:comment>
      This is the basic ontology that defines the shared abstract semantics of all CC/PP 
      application domains by introducing the concepts that constitute the knowledge base 
      for the construction of profiles and the definition of vocabularies of attributes.
      This ontology, except the part that defines an extension vocabulary, is not intended 
      to supersede the usual vocabularies that introduce the RDF basics to reference the CC/PP 
      concepts. It just provides a fixed home to the shared CC/PP structural and semantic concepts,
      not to the terms that can be used to leverage these concepts. Each particular implementation 
      of the CC/PP concepts (e.g., the structural vocabulary defined by the CC/PP specification
      or those ones of UAProf's) can map the terms defined in its own naming space to the 
      abstract concepts here introduced, through a simple ontology, without the need of 
      modifying its vocabulary schema or replacing, in such an ontology, the definition of
      the entire schema itself.
      This way, a semantic CC/PP processor like SADiC can grant rigorous cross-interoperability
      between different CC/PP domains that share the semantics of the same basic concepts but that
      "locate" the terms for referencing them within different namespaces. 
    </rdfs:comment>
  </owl:Ontology>

  <!-- ****************** BASIC CONCEPTS ********************* -->

  <owl:Class rdf:ID="Component">
    <rdfs:subClassOf rdf:resource="&rdfs;Resource" />
    <rdfs:comment>
      This class represents the semantic abstraction of the concept of profile component.
      It is the semantic counterpart of every root component type defined by whatever structural 
      vocabulary that implements the basic CC/PP concepts. All profile components are instances 
      of this class. 
    </rdfs:comment>
  </owl:Class>

  <owl:Class rdf:ID="ComponentType">
    <rdfs:subClassOf rdf:resource="&rdfs;Class" />
    <owl:unionOf rdf:parseType="Collection">
      <owl:Class>
        <owl:oneOf rdf:parseType="Collection">
          <owl:Thing rdf:about="#Component"/>
        </owl:oneOf>
      </owl:Class>
      <owl:Restriction>
        <owl:onProperty rdf:resource="&rdfs;subClassOf" />
        <owl:allValuesFrom rdf:resource="#ComponentType" />
      </owl:Restriction>
    </owl:unionOf>
    <rdfs:comment>
      This is an utility class that groups all possible component classes for convenience.
    </rdfs:comment>
  </owl:Class>

  <rdf:Property rdf:ID="component">
    <rdfs:domain rdf:resource="&rdfs;Resource" />
    <rdfs:range rdf:resource="#Component" />
    <rdfs:comment>
      This property represents the semantic abstraction of the basic RDF mechanism to instance
      the structure of a profile within an RDF data model. It represents the semantic counterpart
      of each analogous property defined by whatever structural vocabulary that implements the 
      basic CC/PP concepts. It is trough such a property that the components of a profile
      are instanced. The domain of this property has been asserted to be generic in order to
      maintain the highest level of abstraction and to avoid strict formal constraints.
      However, the axioms for advanced reasoning provide rigorous means to deduce that  
      RDF resources that have profile components are profiles themselves.
    </rdfs:comment>
  </rdf:Property>

  <rdf:Property rdf:ID="defaults">
    <rdfs:domain rdf:resource="#Component" />
    <rdfs:range rdf:resource="#Component" />
    <owl:differentFrom rdf:resource="#component" />
    <rdfs:comment>
      This property represents the semantic abstraction of the mechanism to indicate default 
      settings for a component within a profile. It represents the semantic counterpart
      of each analogous property defined by whatever structural vocabulary that implements the 
      basic CC/PP concepts. The object of such a property is a component that could be defined
      in an external profile and whose attributes represent the default prerogatives of the
      profile component that declares to have defaults. These default attribute-value pairs are
      to be considered only if the component does not declares directly the same attribute properties:
      in this case the values of directly declared attributes take precedence and override the 
      default values.
    </rdfs:comment>
  </rdf:Property>

  <owl:Class rdf:ID="StructuralProperty">
    <rdfs:subClassOf rdf:resource="&rdf;Property" />
    <owl:oneOf rdf:parseType="Collection">
      <owl:Thing rdf:about="#component"/>
      <owl:Thing rdf:about="#defaults"/>
    </owl:oneOf>
    <rdfs:comment>
      This class is unnecessary and simply groups together the structural properties for
      convenience.
    </rdfs:comment>
  </owl:Class>


  <owl:Class rdf:ID="Attribute">
    <rdfs:subClassOf rdf:resource="&rdf;Property" />
    <owl:intersectionOf rdf:parseType="Collection">
      <owl:Class rdf:about="&rdf;Property" />
      <owl:Restriction>
        <owl:onProperty rdf:resource="&rdfs;domain" />
        <owl:allValuesFrom rdf:resource="#ComponentType" />
      </owl:Restriction>
      <owl:Class>
        <owl:complementOf rdf:resource="#StructuralProperty" />
      </owl:Class>
    </owl:intersectionOf>
    <rdfs:comment>
      This class represents the semantic abstraction of the concept of attribute. 
      It defines an attribute property as any RDF property that can be asserted for  
      a profile component and that is not a structural property.
    </rdfs:comment>
  </owl:Class>

  <!-- **************** EXTENSION VOCABULARY ***************** -->

  <owl:Class rdf:ID="ResolutionRule">
    <rdfs:subClassOf rdf:resource="&rdfs;Resource" />
    <rdfs:comment>
      This class introduces the concept of resolution rule. A resolution rule is intended
      as a label that is associated with an attribute property and that implicitly indicates 
      the behavior to be adopted when, while merging multiple profiles, multiple occurrences 
      of the same attribute are found for the same logical profile component. A resolution 
      rule can be associated with a vocabulary attribute through the "resolution" property. The 
      definition of a resolution rule as a generic RDF resource provides the maximum of flexibility
      and interoperability since the leveraging of the RDF URI references grants the universal and 
      unambiguous identification of every particular rule defined by whatever vocabulary and prevents 
      from the risk of potential inconsistencies caused by the overloading, by different vocabularies,
      of the same contextual term.
    </rdfs:comment>
  </owl:Class>

  <rdf:Property rdf:ID="resolution">
    <rdfs:domain rdf:resource="#Attribute" />
    <rdfs:range rdf:resource="#ResolutionRule" />
    <rdfs:comment>
      This property provides the mechanism to associate a resolution rule to an attribute property.
    </rdfs:comment>
  </rdf:Property>

  <owl:Class rdf:ID="ContainerClass">
    <rdfs:subClassOf rdf:resource="&rdfs;Class" />
    <owl:unionOf rdf:parseType="Collection">
      <owl:Class>
        <owl:oneOf rdf:parseType="Collection">
          <owl:Thing rdf:about="&rdf;Container"/>
          <owl:Thing rdf:about="&rdf;Bag"/>
          <owl:Thing rdf:about="&rdf;Seq"/>
          <owl:Thing rdf:about="&rdf;Alt"/>
        </owl:oneOf>
      </owl:Class>
      <owl:Restriction>
        <owl:onProperty rdf:resource="&rdfs;subClassOf" />
        <owl:allValuesFrom rdf:resource="#ContainerClass" />
      </owl:Restriction>
    </owl:unionOf>
    <rdfs:comment>
      This is an utility class that groups together all possible container classes for convenience.
    </rdfs:comment>
  </owl:Class>
  
  <owl:Class rdf:ID="ComplexRangeProperty">
    <rdfs:subClassOf rdf:resource="&rdf;Property" />
    <owl:intersectionOf rdf:parseType="Collection">
      <rdfs:Class rdf:about="&rdf;Property" />
      <owl:Restriction>
        <owl:onProperty rdf:resource="&rdfs;range" />
        <owl:allValuesFrom rdf:resource="#ContainerClass" />
      </owl:Restriction>
    </owl:intersectionOf>
    <rdfs:comment>
      This class represents the RDF properties whose range values are RDF containers.
      It is an utility class that is leveraged to solve the so called "long range" problem,
      i.e., the intrinsic inability of RDF Schema of providing formal means to specify of what 
      type should be the elements of an RDF container in cases where the range values of a property 
      are constrained to be of such a structured type.
      This class serves only to provide a semantic constraint to the "longRange" property. It should 
      not be referenced in any vocabulary since to declare the complete data type of a container-valued 
      property it is sufficient to add a "longRange" assertion for such a property (intended as a
      RDF resource) and indicate as value the RDF class representing the type of the container's
      elements. Obviously, if as range of the property it has not been indicated a container class, a
      "longRange" assertion for this property is not admitted since it would constitute a violation
      of the semantic constraints.      
    </rdfs:comment>
  </owl:Class>

  <rdf:Property rdf:ID="longRange">
    <rdfs:domain rdf:resource="#ComplexRangeProperty" />
    <rdfs:range rdf:resource="&rdfs;Class" />
    <rdfs:comment>
      This property overcomes the abovementioned "long range" problem and serves to indicate
      of what type should be the elements of a container that is indicated as the value an
      RDF property in cases where such a property declares as range a container type. 
    </rdfs:comment>
  </rdf:Property>

  <owl:Class rdf:ID="StructuredAttribute">
    <rdfs:subClassOf rdf:resource="#ComplexRangeProperty" />
    <owl:intersectionOf rdf:parseType="Collection">
      <owl:Class rdf:about="#Attribute" />
      <owl:Class rdf:about="#ComplexRangeProperty" />
    </owl:intersectionOf>
    <rdfs:comment>
      This class is unnecessary and represents the structured-valued attribute properties, i.e.,
      the attributes whose values should be RDF containers.
    </rdfs:comment>
  </owl:Class>

  <!-- ***** EXAMPLE OF USE OF THE EXTENSION VOCABULARY

      The following example shows how the extension vocabulary can be leveraged in a simple way
      (in conjunction with any existing CC/PP structural vocabulary) to define a vocabulary of 
      attributes and specifying formally its complete semantics:
 
         <ext-voc:ResolutionRule rdf:ID="Append" />

         <ccpp:Attribute rdf:ID="exampleAttribute">
           <rdfs:domain rdf:resource="http://www.w3.org/2002/11/08-ccpp-schema#Component" />
           <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" />
           <ext-voc:longRange rdf:resource="http://www.w3.org/2002/11/08-ccpp-schema#integer" />
           <ext-voc:resolution rdf:resource="#Append" />
         </ccpp:Attribute>

  ************************************************************ -->

  <!-- ************ AXIOMS FOR ADVANCED REASONING ************ -->

  <!-- The following advanced axioms are not thought for any specific practical use.
       They are provided here only to empathize the generality of the semantic architecture
       defined by this ontology and to enforce its consistency. -->
 
  <owl:Class rdf:ID="ProfileStatement">
    <rdfs:subClassOf rdf:resource="&rdf;Statement" />
    <owl:intersectionOf rdf:parseType="Collection">
      <rdfs:Class rdf:about="&rdf;Statement" />
      <owl:Restriction>
        <owl:onProperty rdf:resource="&rdf;predicate" />
        <owl:hasValue>
          <rdf:Description rdf:about="#component" />
        </owl:hasValue>
      </owl:Restriction>
    </owl:intersectionOf>
  </owl:Class>

  <owl:Class rdf:ID="Profile">
    <rdfs:subClassOf rdf:resource="&rdfs;Resource" />
    <owl:intersectionOf rdf:parseType="Collection">
      <rdfs:Class rdf:about="&rdfs;Resource" />
      <owl:Restriction>
        <owl:onProperty>
          <owl:ObjectProperty>
            <owl:inverseOf>
              <owl:ObjectProperty rdf:about="&rdf;subject" />
            </owl:inverseOf>
          </owl:ObjectProperty>
        </owl:onProperty>
        <owl:allValuesFrom rdf:resource="#ProfileStatement" />
      </owl:Restriction>
    </owl:intersectionOf>
  </owl:Class>

</rdf:RDF>

Top

References

[1] SADiC: the Semantic API for the Delivery Context, http://www.the-web-middle-earth.com/sadic/

[2] World Wide Web Consortium, http://www.w3.org

[3] W3C Device Independence Activity, http://www.w3.org/2001/di/

[4] R. Gimson. "Device Independence Principles", W3C Working Draft 18 September 2001, http://www.w3.org/TR/2001/WD-di-princ-20010918/

[5] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler. "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, http://www.w3.org/TR/REC-xml

[6] W3C Resource Description Framework, http://www.w3.org/RDF/

[7] O. Lassila, R. Swick. "Resource Description Framework (RDF) Model and Syntax Specification", W3C Recommendation 22 February 1999, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/

[8] F. Manola, E. Miller. "RDF Primer", W3C Working Draft 23 January 2003, http://www.w3.org/TR/2003/WD-rdf-primer-20030123/

[9] G. Klyne, J. Carroll. "Resource Description Framework (RDF): Concepts and Abstract Syntax", W3C Working Draft 23 January 2003, http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/

[10] D. Brickley, R.V. Guha. "RDF Vocabulary Description Language 1.0: RDF Schema", W3C Working Draft 23 January 2003, http://www.w3.org/TR/2003/WD-rdf-schema-20030123/

[11] Early W3C CC/PP Working Group, http://www.w3.org/Mobile/CCPP/

[12] G. Klyne, F. Reynolds, C. Woodrow, H. Ohto, J. Hjelm, M. Butler, L. Tran. "Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies", W3C Working Draft, 25 Mar 2003, http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030325/

[13] M. Nilsson, J. Hjelm, H. Ohto. "Composite Capabilities/Preference Profiles: Requirements and Architecture", W3C Working Draft 21 July 2000, http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/

[14] Open Mobile Alliance (OMA), http://www.openmobilealliance.org

[15] Early WAP Forum. User Agent Profiling Specification (WAP-174-UAPROF-19991110-a), Version 10 November 1999, http://www1.wapforum.org/tech/terms.asp?doc=SPEC-UAProf-19991110.pdf 
(See also the WAP Specification Information Notes on "WAP-174-UAPROF")

[16] Early WAP Forum. User Agent Profiling Specification, Version 20 October 2001, http://www1.wapforum.org/tech/terms.asp?doc=WAP-248-UAProf-20011020-a.pdf 
(See also the WAP Specification Information Notes on "WAP-248-UAPROF")

[17] OMA. User Agent Profile, Version 1.1, http://www.openmobilealliance.org/omacopyrightNEW.asp?doc=OMA-UAProf-v1_1-20021212-C.zip

[18] W3C Semantic Web Activity, http://www.w3.org/2001/sw/

[19] W3C Web Ontology (WebOnt) Working Group, http://www.w3.org/2001/sw/WebOnt/

[20] D. L. McGuinness, F. van Harmelen. "OWL Web Ontology Language Overview", W3C Working Draft 31 March 2003, http://www.w3.org/TR/2003/WD-owl-features-20030331/

[21] F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, L.A. Stein. "OWL Web Ontology Language Reference", W3C Working Draft 31 March 2003, http://www.w3.org/TR/2003/WD-owl-ref-20030331/

[22] J. Heflin. "Web Ontology Language (OWL) Use Cases and Requirements", W3C Working Draft 31 March 2003, http://www.w3.org/TR/2003/WD-webont-req-20030331/


Top

For information, comments or suggestions contact the Webmaster.
Copyright (c) 2003 Francesco Cannistrà.
All rights reserved.