- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Wed, 27 Mar 2013 16:27:46 -0400
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- CC: Kingsley Idehen <kidehen@openlinksw.com>
hello kingsley. On 2013-03-27 13:02 , "Kingsley Idehen" <kidehen@openlinksw.com> wrote: >On 3/27/13 2:52 PM, Wilde, Erik wrote: >> in this particular case, i would expect the content to be provenance >> statements in RDF, and a client POSTing such a resource would use the >> PROV-DM vocabulary, for example informing the pingback container that it >> just used something >> (http://www.w3.org/TR/2013/PR-prov-dm-20130312/#term-Usage). >Assuming I am accurately processing the statement above. Here's a >"Devil's advocate" style question: >Why are vocabularies (without any detailed mime types and hypermedia >interaction model docs) acceptable in this RDF model based usecase >scenario? because we're a platform and don't really tell others how to design their scenarios. we just build interactions for LDP, and that includes interaction affordances with what unfortunately so far has been called "binary resources", even though it just refers to any kind of payload (as opposed tp LDP stuff we care about). if they POST PROV data as text/turtle, that's fine. if they POST it as text/prov+turtle, that's fine, too. as long as the LPD server accepts these media types, it simply accepts the data as content, and echoes it when a GET request is received. from the LDP point of view, it's no different from somebody doing things with image/jpeg. i think this was very nicely echoed in james comments regarding callimachus: they just decided to treat POSTed RDF a little different than POSTed JPEGs by storing it in a named graph (to maybe run queries on that graph, i suppose, or maybe support other services they may provide), but in the end this simply means they store this resource as it is, so that they can return it as it was POSTed. if they hadn't any requirements for additional services for RDF resources, they could also just store it as CLOB/BLOB. cheers, dret.
Received on Wednesday, 27 March 2013 20:28:40 UTC