DESCRIBE - description of a resource

here is a work in progress proposal to update the DESCRIBE section 10.3  
of SPARQL document (partly reworking some text and examples provided by  
Andy et al.)

	http://www.w3.org/2001/sw/DataAccess/rq23/

$Revision: 1.139 $ of $Date: 2004/11/22 16:52:02 $

Comments and inputs welcome - I will keep on brainstorming and drafting  
more...

============================

10.3 Descriptions of Resources

The RDF model heavily relies on URI identifiers to unambiguously  
identify and reference resources being described, together with  
properties relating them. While RDF explicitly requires property nodes  
to be URI to unambiguously identify their semantics, subject and object  
nodes can also be identified using bNodes. Such bNodes can be  
associated with some well-known unambiguous properties (e.g.  
foaf:mbox_sha1sum or foaf:homepage) to allow a client to  
reference-by-description a certain piece of data.

It is important to note, that independently from the resource  
identification method used:

    1) multiple overlapping descriptions of a resource from different  
sources are possible
    2) being the RDF data semi-structured, the definition and  
understanding of what actually provides a description of a resource  
(piece of data
         or unit of information) is carefully left to the application
    3) each description of a resource might involve several different  
vocabularies which semantics might not be all a priori known
    4) each description of a resource might involve several different  
related resources

Definition: Description of a resource

    It is a representation of a unit of information associated with a  
resource which is considered useful in understanding,
    accessing, interacting, and/or manipulating that resource itself.

While SPARQL SELECT queries can provide simple descriptions of  
resources by matching a well-known set of graph-patterns against a  
single Data Graph, it is generally insufficient if it is not possible  
to specify the exact shape of the information to be extracted.

The SPARQL DESCRIBE clause (together with its well-defined RDF data  
access protocol [1]) provides a more general method to ask an open  
question about a certain resource. The resource being inquired can  
either be a URI or a bNode referenced-by-description using the WHERE  
clause. The results are a single RDF graph containing a description of  
the resource. The RDF returned is the choice of the  deployment and may  
be dependent on the query processor implementation, data source and  
local configuration.  It should be the useful information the server   
has (within security matters outside of SPARQL) about a resource.  It  
may include information about other resources: the RDF data  for a book  
may also include details of the author.

For example, asking about <http://www.w3.org> when asking the CVS  
server might return information about the version history.  Asking the  
web server might return traffic statistics.

Sometimes, the client does not know exactly what information to expect  
of a source.  When browsing the web, of browsing an RDF space, the user  
is involved and controls the navigation.  One use of SPARQL DESCRIBE is  
to grab "meaningful" chunks of the remote RDF Data Graph so that it can  
be navigated.

Another use of DESCRIBE could be to provide the I2C method of a URN  
DDDS [2] based service, or a more modern getMetadata() method over a  
Life Science Identifier URN (LSID) [3] Web service. Finally, DESCRIBE  
may be used to locate subgraphs for update or deletion on a given RDF  
repository providing a SPARQL interface. Or it might be used to handle  
structures like RDF collections and containers, which generally require  
ad-hoc complex computations to carry out items identifiers.

A simple query such as

PREFIX ent:  <http://myorg.example/employees#>
DESCRIBE ?x WHERE (?x ent:employeeId "1234")

might return a description of the employee and some other  potentially  
useful details:

@prefix foaf:   <http://xmlns.com/foaf/0.1/> .
@prefix vcard:  <http://www.w3.org/2001/vcard-rdf/3.0> .
@prefix myOrg:   <http://myorg.example/employees#> .

_:a     myOrg:employeeId    "1234" ;
         foaf:mbox_sha1sum   "ABCD1234" ;
         vcard:N
          [ vcard:Family       "Smith" ;
            vcard:Given        "John"  ] .

  foaf:mbox_sha1sum  rdf:type  owl:InverseFunctionalProperty .

which includes the bNode closure for the vcard vocabulary vcard:N. For  
a vocabulary such as FOAF, where the resources are typically bNodes,  
returning sufficient information to  identify a node such as the  
InverseFunctionalProperty  foaf:mbox_sha1sum as well information which  
as name  and other details recorded would be appropriate. In the  
example,  the match to the WHERE clause was returned but this is not   
required.

In the returned graph there is information about one of the  properties  
that the query server has deemed to be relevant and  helpful in further  
processing.

DESCRIBE ?x ?y WHERE (?x ns:marriedTo ?y)

When there are multiple resources found, the RDF data for each is  
merged into the result graph.

A URI can also be provided directly:

DESCRIBE <http://example.org/>

10.3.1 CBD - Concise Bounded Description

Even though the SPARQL DESCRIBE action is meant to be completely  
agnostic to the particular algorithm used by sever to answer the query,  
this specification non-normatively recommend where possible to adopt  
the CBD - Concise Bounded Description algorithm [  
http://www.w3.org/Submission/CBD/ ]. It is in our hope that by widely  
adopting the CBD definition about description of a resource, a basic  
level of interoperability between different SPARQL services will be  
possible.

( here we could perhaps repeat the CBD definition and algorithm from  
Patrick W3C Note, perhaps rephrased in term of our spec )

( plus integrate some comments and observations from EricP  
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/ 
0017.html )

10.3.2 Basic Cut Algorithm

( this should correspond to the "bNode closure" definition - see "RDF  
Objects" paper section 4.3.1 at  
http://www.hpl.hp.com/techreports/2002/HPL-2002-315.html as well as  
Joseki Fetch data objects http://www.joseki.org/RDF_data_objects.html )


References

[1] SPARQL Protocol for RDF
       http://monkeyfist.com/kendall/sparql-protocol-simplex/
[2] Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform  
Resource Identifiers (URI) Resolution Application
       http://www.ietf.org/rfc/rfc3404.txt
[3] Life Sciences Identifiers
       http://www.omg.org/cgi-bin/doc?dtc/04-05-01


Alberto

-
Alberto Reggiori, Senior Partner, R&D @Semantics S.R.L.
alberto@asemantics.com  www.asemantics.com
Milan Office, milano@asemantics.com,   +39 0332 667092

Received on Monday, 22 November 2004 23:36:03 UTC