Re: Using a "GRDDL" source document as RDF payload in the GraphStore Protocol?

+1

On 2012-08-18, at 10:37, Andy Seaborne wrote:

> Chime,
> 
> I like the idea of adding some text that says, roughly, "if you can get RDF out of it, then that's the RDF body" and I agree it's not a substantive change.
> 
> I would suggest being more general, and less GRDDL specific.
> 
> "The server may discover the RDF payload by processing the incoming HTTP body.  For example, if the Content-Type header is 'application/xml' and the included XML document is associated with a GRDDL transformation [GRDDL], and the implementation may process the incoming request as per GRDDL."
> 
> No use of RFC word  because 'MUST' because it is conditional on an extension anyway.
> 
> There are other examples.
> 
> JSON-LD.  While it can all be turned into triples, the JSON you get back out will loose the micro-JSON syntax and layout so it's not a perfect round trip for a JSON application.  (It should be for an RDF application.)
> 
> Some don't necessarily have distinguishing have content type as far as I know:  RDFa, microdata, or schema.org or OGP.
> 
> 	Andy
> 
> 
> On 17/08/12 15:53, Chime Ogbuji wrote:
>> I'm in the middle of implementing a GraphStore Protocol implementation for Akamu's GRDDL-like system [1].  It would allow me to be able to exercise the tests for this protocol (for which I have an ACTION - once we determine whether or not to have a manifest for it) as I write them.  It would also provide a second implementation (I believe Fuseki is the only one currently) and would be very straightforward to do.  However, as you can see, the DiglotFileSystem uses a custom XML syntax as a (persisted) serialization for a named RDF graph, so it got me thinking about whether GRDDL source documents could be used with the GSP.
>> 
>> Looking at the GraphStore protocol in its current form, the text doesn't seem to preclude the use of the protocol in this way, if the implementation is "GRDDL-aware" (using the example from section  [2] of the GRDDL specification):
>> 
>> PUT /rdf-graph-store?graph=..graph_uri.. HTTP/1.1
>> Host: example.com
>> Content-Type: application/xml
>> 
>> 
>> <purchaseOrder
>>    orderDate="1999-10-20"
>>    xmlns="http://www.w3.org/2003/g/po-ex">
>>    <shipTo country="US">
>>      <name>Alice Smith</name>
>>      <street>123 Maple Street</street>
>> 
>> 
>>    </shipTo>
>> </purchaseOrder>
>> 
>> However, I would like to make this capability explicit in the specification by adding a new sentence after this third sentence of the second paragraph of 5 Graph Operations:
>> 
>> "For operations involving an RDF payload (PUT and POST), the server MUST parse the RDF payload according to media type specified in the Content-Type header if it is provided in the request."
>> 
>> That says:
>> 
>> "Note that if the Content-Type header is 'application/xml', the included XML document is associated with a GRDDL transformation [GRDDL], and the implementation is a GRDDL-aware agent [GRDDL] then the server MUST parse the GRDDL result [GRDDL] accordingly."
>> 
>> This would not be a substantive change as the mechanics of the protocol would not be changed in any way.  Implementations that are not GRDDL aware would simply respond with 400 Bad Request (as instructed in 5.1 Status Codes).  Those that are, *would* be required to parse the GRDDL-result per:
>> 
>> "the server MUST parse the RDF payload according to media type specified in the Content-Type header if it is provided in the request."
>> 
>> And it would clarify what I think is a useful way in which custom XML serializations can be used to manage a Graph Store
>> 
>> Any thoughts?
>> 
>> [1] http://code.google.com/p/akamu/wiki/DiglotFileSystem
>> [2] http://www.w3.org/TR/grddl/#sec_agt
>> 
> 

-- 
Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ

Received on Monday, 20 August 2012 09:27:43 UTC