CBD - Concise Bounded Description

Abstract

This document [1] defines a concise bounded description of a resource in terms of an RDF graph, as a general and broadly optimal unit of specific knowledge about that resource to be utilized by, and/or interchanged between, semantic web agents.

Table of contents

1. Introduction
2. Definition
3. Example
4. Application Issues
5. Alternative Forms of Description
6. Notes and References

Introduction

As the semantic web [2] emerges and the behavior of automated software agents becomes increasingly directed by formally defined knowledge about resources [3] gathered from disparate sources [4], the need for optimal and consistent interchange of knowledge about specific resources between agents becomes critical to achieving an efficient, globally scalable, and ubiquitous semantic web.

This document defines a concise bounded description of a resource in terms of an RDF graph [5], as a general and broadly optimal unit of specific knowledge about that resource to be utilized by, and/or interchanged between, semantic web agents.

Given a particular node in a particular RDF graph, a concise bounded description is a subgraph consisting of those statements which together constitute a focused body of knowledge about the resource denoted by that particular node. The precise nature of that subgraph will hopefully become clear given the definition, discussion and example provided below.

Optimality is, of course, application dependent and it is not presumed that a concise bounded description is an optimal form of description for every application; however, it is presented herein as a reasonably general and broadly optimal form of description for many applications, and unless otherwise warranted, constitutes a reasonable default response to the request "tell me about this resource".

Definition

Given a particular node (the starting node) in a particular RDF graph (the source graph), a subgraph of that particular graph, taken to comprise a concise bounded description of the resource denoted by the starting node, can be identified as follows:

1. Include in the subgraph all statements in the source graph where the subject of the statement is the starting node;
2. Recursively, for all statements identified in the subgraph thus far having a blank node object, include in the subgraph all statements in the source graph where the subject of the statement is the blank node in question and which are not already included in the subgraph.
3. Recursively, for all statements included in the subgraph thus far, for all reifications of each statement in the source graph, include the concise bounded description beginning from the rdf:Statement node of each reification.

This results in a subgraph where the object nodes are either URI references, literals, or blank nodes not serving as the subject of any statement in the graph.

Example

Given the following RDF graph as input (the source graph):

<?xml version="1.0"?>

<rdf:RDF
   xmlns:rdf  ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs ="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:owl  ="http://www.w3.org/2002/07/owl#"
   xmlns:dc   ="http://purl.org/dc/elements/1.1/"
   xmlns:dct  ="http://purl.org/dc/terms/"
   xmlns:xsd  ="http://www.w3.org/2001/XMLSchema#"
   xmlns:foaf ="http://xmlns.com/foaf/0.1/"
   xmlns:ex   ="http://example.com/">

   <rdf:Description rdf:about="http://example.com/aReallyGreatBook">
      <dc:title>A Really Great Book</dc:title>
      <dc:publisher>Examples-R-Us</dc:publisher>
      <dc:creator>
         <rdf:Description>
            <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
            <foaf:name>John Doe</foaf:name>
            <foaf:mbox>john@example.com</foaf:mbox>
            <foaf:img>
               <rdf:Description rdf:about="http://example.com/john.jpg">
                  <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Image"/>
                  <dc:format>image/jpeg</dc:format>
                  <dc:extent>1234</dc:extent>
               </rdf:Description>
            </foaf:img>
            <foaf:phone rdf:resource="tel:+1-999-555-1234"/>
         </rdf:Description>
      </dc:creator>
      <dc:contributor>
         <rdf:Description>
            <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
            <foaf:name>Jane Doe</foaf:name>
         </rdf:Description>
      </dc:contributor>
      <dc:language>en</dc:language>
      <dc:format>application/pdf</dc:format>
      <dc:rights>Copyright (C) 2004 Examples-R-Us. All rights reserved.</dc:rights>
      <dct:issued rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2004-01-19</dct:issued>
      <rdfs:seeAlso rdf:resource="http://example.com/anotherGreatBook"/>
   </rdf:Description>

   <rdf:Statement>
      <rdf:subject rdf:resource="http://example.com/aReallyGreatBook"/>
      <rdf:predicate rdf:resource="http://purl.org/dc/elements/1.1/format"/> 
      <rdf:object>application/pdf</rdf:object>
      <rdfs:isDefinedBy rdf:resource="http://example.com/book-formats.rdf"/>
   </rdf:Statement>

   <rdf:Statement>
      <rdf:subject rdf:resource="http://xmlns.com/foaf/0.1/Image"/>
      <rdf:predicate rdf:resource="http://purl.org/dc/elements/1.1/format"/> 
      <rdf:object>image/jpeg</rdf:object>
      <rdfs:isDefinedBy rdf:resource="http://example.com/image-formats.rdf"/>
   </rdf:Statement>

   <rdf:Description rdf:about="http://example.com/anotherGreatBook">
      <dc:title>Another Great Book</dc:title>
      <dc:publisher>Examples-R-Us</dc:publisher>
      <dc:creator>June Doe (june@example.com)</dc:creator>
      <dc:format>application/pdf</dc:format>
      <dc:language>en</dc:language>
      <dc:rights>Copyright (C) 2004 Examples-R-Us. All rights reserved.</dc:rights>
      <dct:issued rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2004-05-03</dct:issued>
      <rdfs:seeAlso rdf:resource="http://example.com/aReallyGreatBook"/>
   </rdf:Description>

   <rdf:Description rdf:about="http://example.com/aBookCritic">
      <ex:likes rdf:resource="http://example.com/aReallyGreatBook"/>
      <ex:dislikes rdf:resource="http://example.com/anotherGreatBook"/>
   </rdf:Description>

   <rdf:Property rdf:about="http://xmlns.com/foaf/0.1/mbox">
      <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#InverseFunctionalProperty"/>
   </rdf:Property>

</rdf:RDF>

The concise bounded description of http://example.com/aReallyGreatBook corresponds to the following subgraph:

<?xml version="1.0"?>

<rdf:RDF
   xmlns:rdf  ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs ="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:owl  ="http://www.w3.org/2002/07/owl#"
   xmlns:dc   ="http://purl.org/dc/elements/1.1/"
   xmlns:dct  ="http://purl.org/dc/terms/"
   xmlns:xsd  ="http://www.w3.org/2001/XMLSchema#"
   xmlns:foaf ="http://xmlns.com/foaf/0.1/">

   <rdf:Description rdf:about="http://example.com/aReallyGreatBook">
      <dc:title>A Really Great Book</dc:title>
      <dc:publisher>Examples-R-Us</dc:publisher>
      <dc:creator>
         <rdf:Description>
            <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
            <foaf:name>John Doe</foaf:name>
            <foaf:mbox>john@example.com</foaf:mbox>
            <foaf:img rdf:resource="http://example.com/john.jpg"/>
            <foaf:phone rdf:resource="tel:+1-999-555-1234"/>
         </rdf:Description>
      </dc:creator>
      <dc:contributor>
         <rdf:Description>
            <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
            <foaf:name>Jane Doe</foaf:name>
         </rdf:Description>
      </dc:contributor>
      <dc:language>en</dc:language>
      <dc:format>application/pdf</dc:format>
      <dc:rights>Copyright (C) 2004 Examples-R-Us. All rights reserved.</dc:rights>
      <dct:issued rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2004-01-19</dct:issued>
      <rdfs:seeAlso rdf:resource="http://example.com/anotherGreatBook"/>
   </rdf:Description>

   <rdf:Statement>
      <rdf:subject rdf:resource="http://example.com/aReallyGreatBook"/>
      <rdf:predicate rdf:resource="http://purl.org/dc/elements/1.1/format"/> 
      <rdf:object>application/pdf</rdf:object>
      <rdfs:isDefinedBy rdf:resource="http://example.com/book-formats.rdf"/>
   </rdf:Statement>

</rdf:RDF>

Application Issues

Representations versus Descriptions

The web, as traditionally defined [6], [7], is concerned with providing representations of resources. Representations can essentially be anything associated with the resource which is considered useful in understanding, accessing, interacting, and/or manipulating that resource, such that the representation conveys information about the state of the resource. This is fine for visual presentation to humans browsing the web, who can deal with a great amount of variety, inconsistency, and ambiguity while still deriving benefit from the representations provided. It is this flexibility and unconstrained richness of what representations can be that is one of the factors responsible for the tremendous success of the web.

However, semantic web agents (at present at least) are not able to deal as well with the broad range of possible representations which might be associated with a resource; and in nearly all cases, are unable to make any use of such representations, as they are typically intended for human rather than machine consumption. Semantic web agents, not being anywhere near as intelligent as most humans, require information which is explicit and formally defined. In short, semantic web agents need concise, bounded descriptions of resources, expressed in a machine understandable language, rather than seemingly arbitrary representations which to agents are usually semantically opaque.

Concise bounded descriptions of resources can be considered to be a form of representation, however they are a highly specialized form and not the most usual or obvious form in a web primarily intended for human consumption. They are, however, a key form of representation which semantic web agents need in order to reason about such resources and adjust their behavior accordingly.

Determination of the Source Graph

The starting point for obtaining a concise bounded description is a particular node in a particular RDF graph. Determination of the particular source graph from which the description is to be obtained is (primarily) a system issue.

The source graph does not necessarily correspond exactly to the set of statements persistently managed by a given system in a triple store, or set of triple stores. There may be statements maintained by the system which are sensitive and not intended to be accessible to the public at large. There may be statements maintained by the system which are specific only to the internal functioning of the system, and not relevant or interesting to most agents. The system may employ a reasoning component which is able to dynamically infer new statements from those persistently stored. The system may allow access to certain statements to certain users but not to others.

So, in practice, the actual graph which a particular service utilizes as the source graph for returning concise bounded descriptions in response to query requests to that service, may be a virtual graph that only exists in a transient state at run-time, during the execution of a particular query.

Thus, issues such as security, visibility, inference, etc. which may govern the determination of the particular graph employed by a given service in a given context to satisfy a given request are distinct from the identification of a particular concise bounded description once that source graph has been determined.

However, while such issues are functionally disjunct, that does not mean they cannot be addressed in parallel, when processing a request for a concise bounded description. E.g., in the Nokia Semantic Web Server [8] implementation [9], identification of statements belonging to a particular concise bounded description are determined using inference rules, which may be evaluated in parallel with select RDFS [5], OWL [10], and service specific inference rules. The source graph is not first constructed, by applying the RDFS, OWL, and other inference rules, from which the concise bounded description is then afterwards obtained; rather, all are performed as a single logical step, implemented using the same reasoning machinery.

Query and Application Programming Interfaces

Again, as stated above, the starting point for obtaining a concise bounded description is a particular node in a particular RDF graph. How you identify that particular node in the source graph is an interface issue.

Also, in some cases, the source graph may be explicitly named [11] and therefore identification of the source graph by name may also be a potential interface issue.

Different query and application programming interfaces can provide different means by which the particular graph and/or the particular node in that graph might be identified and referred to when requesting a concise bounded description. And while different interfaces may identify that node and that graph by different means, once that node and graph are identified, obtaining a concise bounded description can proceed the same for all cases, irrespective of how the starting point was arrived at.

However, insofar as particular forms of descriptions are concerned, it is important to note that the form of description can introduce requirements on the functionality of the interface (and visa versa) which must be satisfied if all statements contained in a given source graph are to be accessible via at least one query expressable via that interface.

For example, to provide access to concise bounded descriptions, a service requires only the simplest, minimal query interface -- one in which only a single, known, and predefined graph is accessible (and need not be explicitly specified) and where the URI label of a subject node is specified as the only query parameter. An example of such a query interface is the basic URIQA query interface [4]. Given a source RDF graph which is accessible via the basic URIQA interface, which takes a URI as its sole query parameter and returns a concise bounded description (if successful), every statement in that source graph is accessible via that simple interface such that, if every URI which occurs as the subject of a statement in that source graph is known, then if the results of executing a basic URIQA query for each such URI are merged together, the merged graph will equal the source graph being queried.

Some alternative forms of description, such as those presented below, which explicitly accomodate inverse functional properties, require slightly more comprehensive query interfaces if all statements in the source graph are to be accessible via the same query interface. Specifically, in addition to basic URIQA-like queries, they must provide for queries comprised minimally of a unique arc label for the inverse functional property as well as an object node label. If a query service provided access to an RDF graph using only the basic URIQA query interface, but returned inverse functional concise bounded descriptions, rather than the more general concise bounded descriptions, then there could be statements in the source graph relating to resources denoted by blank nodes which are inaccessible via that query interface, because they would not be included in any concise bounded description accessible via the basic URIQA interface, due to the occurrence of inverse functional properties in statements about such a resource, and one cannot otherwise explicitly inquire about that resource using the URIQA query interface, as that interface does not enable one to directly inquire about a resource denoted by a blank node.

This should not be seen as a shortcoming inherent in either the query interface or the form of description employed, but simply as an example of how the interface via which requests about resources are made and the form of description provided in responses to such requests must be functionally matched. For some applications, requirements may dictate first selecting a particular interface, in which case the form(s) of description employed in responses should take into account the capabilities of the interface to ensure that all statements are accessible via that interface in some response. For other applications, requirements may dictate first selecting the form(s) of description, in which case the interface must take into account the form(s) of the description to ensure that all statements are accessible via that interface in some response.

The more general and capable the query interface, the more options one has regarding suitable forms of descriptions. Though it should be noted that the more general the query interface, and the more variable the forms of description returned, the greater the implementational and processing burden for both the requesting and responding agents. That said, even a service employing a fully general query interface and supporting numerous possible forms of descriptions can offer significant benefit to arbitrary semantic web agents by providing a concise bounded description as its default form of description.

Managing Magnitude

In certain cases, for certain source graphs, a concise bounded description may exceed what is a useful magnitude for a given application or requesting agent, and the service may choose to employ various means to limit the number of statements included in a response in order to address practical capacity and performance issues.

Such practical limitations on the magnitude of responses should be employed only when absolutely necessary, and while a partial description may still be returned, the service should clearly indicate to the requesting agent that such limits have been reached and that the response does not constitute a complete concise bounded description per the original request. The requesting agent, being made aware of the magnitude limitations, can then make informed decisions about how or whether to proceed based on the incomplete information it has been provided.

A system may also allow the requesting agent to specify its preferred limits, where applicable. Though, whether the limits are defined by the system or specified by the requesting agent, it should nevertheless be clear in the response whether any such limit was reached, and that the response does not otherwise constitute a complete description.

The following are only a few possible ways to limit the magnitude of responses. There are surely others.

Limit the (over)use of Blank Nodes

The most common cause of unmanagable magnitudes in responses corresponding to a concise bounded description is when the source graph constitutes a large body of knowledge which extensively employs blank nodes to denote "significant" resources, and which relies on the use of inverse functional properties to uniquely refer to such "significant" blank node denoted resources. Many FOAF [12] specific knowledge bases exhibit such characteristics.

Thus, it is conceivable that for a given source graph, a request for a concise bounded description of a resource per a particular node in that graph may result in a subgraph that contains nearly all of the statements in the source graph, or is even equal to the source graph, because the description did not terminate at a useful boundary, given the extensive use of blank nodes.

A simple way to rectify this particular problem is, obviously, to limit the use of blank nodes.

This can be done in several ways. One can simply assign dynamically generated URIs employing UUIDs, e.g.

http://example.com/id/12bf7f7a-2698-461a-b20a-587cfcadba80

to all otherwise unnamed ("blank") nodes, thus providing explicit points of termination in concise bounded descriptions which otherwise would not terminate at a blank node; as well as explicit means of reference by which access to descriptions about those particular resources is provided.

One could also adopt the commendable practice of always using specifically assigned http: URIs [6] to denote resources which are expected to occur as the object of multiple statements and/or be commonly referred to in communication between agents, even if statements about such resources might otherwise employ inverse functional properties.

Limiting Path Length

The system can limit the length of any non-cyclic path from the starting node to any other node in the description subgraph; effectively limiting the "depth" of the subgraph from the starting node.

Limiting Total Number of Statements

The system can limit the total number of statements included in the description subgraph; possibly employing a particular sequence by which statements are added to the description subgraph so that the most "significant" or "nearest" statements are included first.

Excluding or Limiting Reifications

The system can exclude statements relating to reifications from the description subgraph; or may limit such statements to only those relevant to a particular purpose, such as provenance.

Alternative Forms of Description

As has been mentioned above, it is expected that some applications may find other forms of resource description more optimal than a concise bounded description. The following are some possible alternative forms of description which can be seen as derivations of the basic form of concise bounded description described above, which may be more suitable for particular applications. These alternative forms of description are not, however, considered to be as general or broadly optimal as a concise bounded description.

Symmetric Concise Bounded Description

A concise bounded description, as defined above, can be seen as an "asymmetric" view of a resource; such that it only includes statements which are expressed along arc paths in the graph which originate from the starting node (outbound arcs); and does not include statements which are expressed along (non-circular) arc paths which terminate at the starting node (inbound arcs).

Statements which are expressed as outbound arcs from a particular node provide primary knowledge about the resource denoted by that node, where that resource is of primary focus (the subject). Statements which are expressed as inbound arc paths to a given node provide secondary knowledge about the resource denoted by that node, where that resource is of secondary focus (the object). While some applications might be concerned about secondary knowledge about a given resource, it is expected that most will be concerned only about primary knowledge. Furthermore, there are particular magnitude issues for descriptions containing such secondary knowledge, as discussed further below.

There is a special form of secondary knowledge which has a direct relation to (possibly implicit) primary knowledge; and that concerns the use of symmetric properties. E.g. consider the properties dct:hasPart and dct:isPartOf. For any statement 'X dct:hasPart Y' we can infer 'Y dct:isPartOf X', and visa versa. It may be the case that in a given graph, there are only statements utilizing one of a pair of symmetric properties, and therefor, a concise bounded description may omit a statement where the starting node occurs as object and thus implicit knowledge which could be inferred from knowledge about the symmetric pair of properties is not accessible in the description. E.g., if in a given graph a given node occurs as the object of a dct:isPartOf statement but no symmetrical dct:hasPart statement exists, a concise bounded description beginning at that node will not include the dct:isPartOf statement and thus the agent recieving the description will not have the necessary knowledge (the dct:isPartOf statement) from which it might infer the symmetrical dct:hasPart statement.

There are various ways to address symmetric properties. One way is to infer such statements on the server side, such that the (inference derived) source graph would in fact include the dct:hasPart statement and thus it would be included in a concise bounded description. This is the approach employed by the Nokia Semantic Web Server [9].

Another approach is to return an alternative form of description, which includes all statements expressed along both outbound and inbound arc paths, terminated in like fashion as a concise bounded description but extending from the starting node in both directions; thus enabling the requesting agent to potentially infer itself any implicit statements based on symmetric property pairs. We can call this derivative of a concise bounded description a symmetric concise bounded description.

Specifically, given a particular node (the starting node) in a particular RDF graph (the source graph), a subgraph of that particular graph, taken to comprise a symmetric concise bounded description of the resource denoted by the starting node, can be identified as follows:

1. Include in the subgraph all statements in the source graph where the object of the statement is the starting node;
2. Recursively, for all statements identified in the subgraph thus far having a blank node subject not equal to the starting node, include in the subgraph all statements in the source graph where the object of the statement is the blank node in question and which are not already included in the subgraph.
3. Recursively, for all statements included in the subgraph thus far, for all reifications of each statement in the source graph, include the symmetric concise bounded description beginning from the rdf:Statement node of each reification.
4. Include in the subgraph the concise bounded description beginning from the starting node.

This produces a subgraph that includes a concise bounded description, given the same starting point, but in addition, includes all inbound arc paths, up to but not beyond a URIref subject node.

Thus, given the source RDF graph presented above, the symmetric concise bounded description of the resource denoted by http://example.com/aReallyGreatBook corresponds to the following subgraph:

<?xml version="1.0"?>

<rdf:RDF
   xmlns:rdf  ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs ="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:owl  ="http://www.w3.org/2002/07/owl#"
   xmlns:dc   ="http://purl.org/dc/elements/1.1/"
   xmlns:dct  ="http://purl.org/dc/terms/"
   xmlns:xsd  ="http://www.w3.org/2001/XMLSchema#"
   xmlns:foaf ="http://xmlns.com/foaf/0.1/"
   xmlns:ex   ="http://example.com/">

   <rdf:Description rdf:about="http://example.com/aReallyGreatBook">
      <dc:title>A Really Great Book</dc:title>
      <dc:publisher>Examples-R-Us</dc:publisher>
      <dc:creator>
         <rdf:Description>
            <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
            <foaf:name>John Doe</foaf:name>
            <foaf:mbox>john@example.com</foaf:mbox>
            <foaf:img rdf:resource="http://example.com/john.jpg"/>
            <foaf:phone rdf:resource="tel:+1-999-555-1234"/>
         </rdf:Description>
      </dc:creator>
      <dc:contributor>
         <rdf:Description>
            <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
            <foaf:name>Jane Doe</foaf:name>
         </rdf:Description>
      </dc:contributor>
      <dc:language>en</dc:language>
      <dc:format>application/pdf</dc:format>
      <dc:rights>Copyright (C) 2004 Examples-R-Us. All rights reserved.</dc:rights>
      <dct:issued rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2004-01-19</dct:issued>
      <rdfs:seeAlso rdf:resource="http://example.com/anotherGreatBook"/>
   </rdf:Description>

   <rdf:Statement>
      <rdf:subject rdf:resource="http://example.com/aReallyGreatBook"/>
      <rdf:predicate rdf:resource="http://purl.org/dc/elements/1.1/format"/> 
      <rdf:object>application/pdf</rdf:object>
      <rdfs:isDefinedBy rdf:resource="http://example.com/book-formats.rdf"/>
   </rdf:Statement>

   <rdf:Description rdf:about="http://example.com/aBookCritic">
      <ex:likes rdf:resource="http://example.com/aReallyGreatBook"/>
   </rdf:Description>

</rdf:RDF>

As mentioned above, there are cases where symmetric concise bounded descriptions have magnitude problems; in particular, when a given node occurs as the object of an exceptionally large number of statements. E.g. given a persistent triple store contaning millions of triples and a source graph which is dynamically inferred from that triple store by a reasoner, which applies all RDF and RDFS closure rules, the symmetric concise bounded description for cases such as rdf:Resource and similar standard and/or proprietary RDF classes could be immense. The managability of this particular form of description will be proportional to how frequently a given node occurs as the object of a statement. For classificatory terms (as well as literal objects, etc.) applications will likely benefit more from either an (asymmetrical) concise bounded description or from a precise query regarding specific usage expressed in a more general purpose query language.

Inverse Functional Concise Bounded Description

As discussed above, in order to managing magnitudes of descriptions where the source graph reflects a substantial use of blank nodes and inverse functional properties, one may employ a special form of description (along with a sufficiently capable query interface) to terminate at, and exclude particular statements about, blank nodes occuring as the subject of one or more statements which are are expressed using an inverse functional property.

Specifically, given a particular node (the starting node) in a particular RDF graph (the source graph), a subgraph of that particular graph, taken to comprise an inverse functional concise bounded description of the resource denoted by the starting node, can be identified as follows:

1. Include in the subgraph all statements in the source graph where the subject of the statement is the starting node;
2. Recursively, for all statements included in the subgraph thus far, for each blank node object:

   IF there exists at least one statement in the source graph having the blank node as subject and where the source graph includes a statement which asserts that the predicate of that statement is rdf:type owl:InverseFunctionalProperty [10],

   THEN

   For each statement in the source graph having the blank node as subject and where the source graph includes a statement which asserts that the predicate of that statement is rdf:type owl:InverseFunctionalProperty:

   • Include the statement in the subgraph; and
   • If the object of the statement is a blank node, include the inverse functional concise bounded description beginning from that blank object node;

   ELSE

   For each statement in the source graph having the blank node as subject:

   • Include the statement in the subgraph; and
   • If the object of the statement is a blank node, include the inverse functional concise bounded description beginning from that blank object node;

3. Recursively, for all statements included in the subgraph thus far, for all reifications of each statement in the source graph, include the inverse functional concise bounded description beginning from the rdf:Statement node of each reification.

Thus, given the source RDF graph presented above, the inverse functional concise bounded description of the resource denoted by http://example.com/aReallyGreatBook corresponds to the following subgraph:

<?xml version="1.0"?>

<rdf:RDF
   xmlns:rdf  ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs ="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:owl  ="http://www.w3.org/2002/07/owl#"
   xmlns:dc   ="http://purl.org/dc/elements/1.1/"
   xmlns:dct  ="http://purl.org/dc/terms/"
   xmlns:xsd  ="http://www.w3.org/2001/XMLSchema#"
   xmlns:foaf ="http://xmlns.com/foaf/0.1/"
   xmlns:ex   ="http://example.com/">

   <rdf:Description rdf:about="http://example.com/aReallyGreatBook">
      <dc:title>A Really Great Book</dc:title>
      <dc:publisher>Examples-R-Us</dc:publisher>
      <dc:creator>
         <rdf:Description>
            <foaf:mbox>john@example.com</foaf:mbox>
         </rdf:Description>
      </dc:creator>
      <dc:contributor>
         <rdf:Description>
            <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
            <foaf:name>Jane Doe</foaf:name>
         </rdf:Description>
      </dc:contributor>
      <dc:language>en</dc:language>
      <dc:format>application/pdf</dc:format>
      <dc:rights>Copyright (C) 2004 Examples-R-Us. All rights reserved.</dc:rights>
      <dct:issued rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2004-01-19</dct:issued>
      <rdfs:seeAlso rdf:resource="http://example.com/anotherGreatBook"/>
   </rdf:Description>

   <rdf:Statement>
      <rdf:subject rdf:resource="http://example.com/aReallyGreatBook"/>
      <rdf:predicate rdf:resource="http://purl.org/dc/elements/1.1/format"/> 
      <rdf:object>application/pdf</rdf:object>
      <rdfs:isDefinedBy rdf:resource="http://example.com/book-formats.rdf"/>
   </rdf:Statement>

</rdf:RDF>

Note that any inverse functional concise bounded description is a subgraph of, or equivalent to, the concise bounded description obtained when starting from the same node in the same RDF graph.

Notes and References

[1] Note on terminology:

This document does not constitute a mathematical presentation of concise bounded descriptions. The use of terms such as "concise", "bounded", "description", "definition", etc. are not to be interpreted according to any special meaning or use as mathematical terms. This document is an English language presentation of a number of ideas which are considered to offer utility to implementors of semantic web or other applications dealing with descriptive metadata. More precise mathematical specifications of these ideas would be welcome and beneficial. This document does not provide them.

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

[3] Architecture of the WWW, Definition of a Resource, http://www.w3.org/TR/webarch/#def-resource

[4] URIQA, http://sw.nokia.com/uriqa/URIQA.html

[5] RDF, RDFS, http://www.w3.org/RDF/

[6] RFC2616 - HTTP 1.1, http://www.ietf.org/rfc/rfc2616.txt

[7] Architecture of the WWW, http://www.w3.org/TR/webarch/

[8] Nokia Semantic Web Server, http://sw.nokia.com

[9] Nokia Semantic Web Server open source distribution, http://swdev.nokia.com/tools

[10] OWL, http://www.w3.org/2004/OWL/

[11] Named Graphs, Provenance and Trust, http://www.hpl.hp.com/techreports/2004/HPL-2004-57.html

[12] FOAF (Friend of a Friend), http://www.foaf-project.org