Hi All:
Thanks for the very useful feedback!

Just to clarify what I want to do:

There are many valuable commerce data resources available in XML and CSV on the Web. It is fairly straightforward to translate them into RDF, e.g. using GoodRelations. Now, whenever I create an RDF representation of that data in a new namespace, I may want to store the meta-data of the original HTTP GET request with which I fetched the XML or CSV file, and attach that meta-data to the resulting RDF graph.

This allows for (1) nice analytics and (2) data cleansing entirely in the SPARQL / RDF world later-on.

So the subject to which the meta-data will be attached will not be the resource URI (because there can naturally be multiple HTTP GET requests for the same resource), but instead the resulting graph or dataset.

I assume the same will be useful in many other application domains and scenarios.

Here is an example:

Assume we have an XML file with company data at
   http://www.heppnetz.de/companies.xml

and we fetch that, convert it to RDF, and republish the data in the namespace

   http://www.example.com/RDFizingResults/dataset1#

Let's further assume that the HTTP GET request to the XML file returned the following HTTP header data:

# Meta-data from fetching the original data
# HTTP/1.1 200 OK
# Date: Mon, 17 Jan 2011 21:31:58 GMT
# Server: Apache
# Last-Modified: Mon, 25 Oct 2010 20:31:25 GMT
# Content-Length: 10971
# Content-Type: application/xml


So the following seems possible and useful:

@prefix void: <http://rdfs.org/ns/void#> .
@prefix http: <http://www.w3.org/2006/http#> .
@prefix headers: <http://www.w3.org/2008/http-headers#> .
@prefix status: <http://www.w3.org/2008/http-statusCodes#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix gr: <http://purl.org/goodrelations/v1#> .
@prefix foo: <http://www.example.com/RDFizingResults/dataset1#> .

# Define an entity for the resulting dataset / graph
foo:dataset a void:Dataset .

# Link the graph to the HTTP header info from the data transformation
foo:dataset rdfs:seeAlso foo:ResponseMetaData .

NOTE: My original question was which predicate to use for this statement. rdfs:seeAlso seems valid, but it maybe suboptimal.
        
# Expose the meta-data from fetching the original data
foo:ResponseMetaData a http:Response ;
        http:httpVersion "1.1" ;
        dct:date "2008-01-11"^^xsd:date ;
        http:statusCodeNumber "200" ;
        http:sc status:statusCode200  ;
        http:headers [ a http:MessageHeader ;
                                   http:fieldName "Server" ;
                                   http:fieldValue "Apache" ] ;
        http:headers [ a http:MessageHeader ;
                                   http:fieldName "Last-Modified" ;
http:fieldValue "2010-1025T20:31:25Z"^^xsd:datetime ] ;
        http:headers [ a http:MessageHeader ;
                                   http:fieldName "Content-Length" ;
                                   http:fieldValue 10971 ] ;
        http:headers [ a http:MessageHeader ;
                                   http:fieldName "Content-Type" ;
                                   http:fieldValue "application/xml" ] .        
      

# Then comes the real instance data, derived from the original source
foo:ACME a gr:BusinessEntity ;
        rdfs:isDefinedBy foo:dataset .

foo:MillerInc a gr:BusinessEntity ;
        rdfs:isDefinedBy foo:dataset .
#  etc. 

Does that sound okay and useful for everybody?

Best
Martin

PS: I omitted the prefix declarations in the example above:

@prefix void: <http://rdfs.org/ns/void#> .
@prefix http: <http://www.w3.org/2006/http#> .
@prefix headers: <http://www.w3.org/2008/http-headers#> .
@prefix status: <http://www.w3.org/2008/http-statusCodes#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix gr: <http://purl.org/goodrelations/v1#> .
@prefix foo: <http://www.example.com/RDFizingResults/dataset1#> .



On 17.01.2011, at 21:21, Shadi Abou-Zahra wrote:

Dear Martin, All,

Just a reminder that you are looking at an old, outdated editors draft of the HTTP-in-RDF Vocabulary. The latest Public Working Draft is here:
- <http://www.w3.org/TR/HTTP-in-RDF10/>

I seem to recall updates to the vocabulary that allow more flexibility to support uses as the one described below by Martin (though I did not check back specifically for that case).

Please note that the W3C/WAI Evaluation and Repair Tools Working Group welcomes comments and feedback on HTTP-in-RDF (despite the long passed deadline). Please send comments to <public-earl10-comme...@w3.org >.

Best,
 Shadi


On 17.1.2011 20:23, Nathan wrote:
William Waites wrote:
* [2011-01-17 16:39:27 +0100] Martin Hepp
<martin.h...@ebusiness-unibw.org> écrit:

] Does anybody know of a standard property for linking a RDF graph to a ] http:GetRequest, http:Connection, or http:Response instance? Maybe
] rdfs:seeAlso (@TBL: ;- ))?

If you suppose that the name of the graph is the same as the
request URI (it will not always be, of course) you can link
in the other direction from http:Request using http:requestURI.
I am not sure that http:requestURI has a standard inverse though.

And remember of course, that the headers are split in to different
groups which relate to different things, many relate to the message (in relation to the request), some relate to the server, some relate to the
entity (an encoded version of the representation for messaging) a few
(really not many) relate to the representation itself, and a couple
relate to the resource itself, the resource being the thing the URI
identifies.

Best,

Nathan



--
Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
 WAI International Program Office Activity Lead   |
W3C Evaluation & Repair Tools Working Group Chair |



Reply via email to