[Mulgara-dev] SPARQL handling of POSTed file uploads

Andy Seaborne andy.seaborne at epimorphics.com
Thu Dec 30 10:39:18 UTC 2010


Interesting discussion - very glad I noticed it ...

On 30/12/10 03:54, Paul Gearon wrote:
> Hi Gregg,
>
> I don't know if Andy is still subscribed to this list, but if so, then
> I'm sure he would have some pertinent observations to add.

Depends on whether this email address can send to this list ...

Gregg - I think your comments are important and you are not alone in the 
sentiments you express.  It would be good if you'd send them to the 
working group comments list <public-rdf-dawg-comments at w3.org>.

The WG (working group) has received significant comments that the 
mention of "RDF knowledge" is unhelpful. It's becoming clear to me that 
the document is not helping a significant number of people in the 
intended audience.

> On Tue, Dec 28, 2010 at 10:06 AM, Gregg Reynolds<dev at mobileink.com>  wrote:
>> On Sun, Dec 26, 2010 at 11:37 AM, Paul Gearon<gearon at ieee.org>  wrote:
>>>
>>> to REST where I could. However, a real protocol is nearly here, and
>>> everything in Mulgara's protocols will need to be updated to comply.
>>> The preliminary document for this is at:
>>>   http://www.w3.org/2009/sparql/docs/http-rdf-update/
>>> It's getting close to final call, so most of this document has been
>>> finalized and we should go ahead and update Mulgara to use it.
>>
>> First impression: lots of problems.  In fact the more I think about it the
>> more I doubt whether the document is even necessary.  The semantics of the
>> HTTP methods are already defined in RFC 2616.  The only need I can see (off
>> the top of my head) is for RDF-specific query syntax (i.e. "graph=...").
>>   But that is not a protocol issue; it's just a naming convention.
>
> I think you're getting a little picky there. Conventions *are* a kind
> of protocol. Also, if you don't follow the convention, then you can't
> communicate with an endpoint that "satisfies the protocol".

For me, the only thing the document adds is the graph identification via 
"?graph=".  The rest is informative description about the correct use of 
HTTP in a RESful fashion.  But then I think the doc should be called 
"SPARQL RESTful protocol".

It is necessary to standardize the use of "?graph=" -- we've had 
implementer driven conventions before and there is always enough 
varation to be painful.

>> The major problem, for me anyway, is the talk about "RDF knowledge".
>> "Knowledge" is not a technical term; I wish the W3C would ban it.
 >
> I disagree. It has a very specific meaning, and the W3C are trying to
> be careful to use it correctly. Knowledge is referring to the
> information that the RDF is encoding, without any reference to how it
> is encoded. It may be RDF/XML, JSON, N3, or one of several other
> formats. Some of those formats may require significant transformation
> to derive the "triples" that forms the basis of RDF. Referring to
> "triples" also tends to imply N3, which they are trying to avoid here.

I agreed with Gregg - a standard protocol is about bytes-on-the-wire and 
changes in state that two systems have to agree on.  How you think out 
the meaning of that state is irrelevant to a standard otherwise you get 
the situation where two systems can address on the bytes and state 
changes, so they work together perfectly well and you can not observe 
disagreement, but if they disagree on the natural language above that do 
they not comply with the standard?

 >>   Sentences
>> like  "However, in using a URI in this way, we are not directly identifying
>> an RDF graph but rather the RDF knowledge that is represented by an RDF
>> document, which serializes that graph." make my eyeballs hurt. To me it
>> reads like bad amateur philosophizing - note the logical
>> incoherence.
>
> I agree that it makes for painful reading, but it's done for a purpose.

I'd say it's arguable whether it's even right.  A URI names a resource 
(by AWWW).  Is the resource "RDF knowledge"? (I refuse to use the terms 
without quotes.) Is an image of a cat knowledge about the cat?  Seems to 
me to be mixing the levels of abstraction up data/information/knowledge. 
  knowledge requires context.

http://en.wikipedia.org/wiki/DIKW

> Part of the reason is that a lot of this stuff has been developed by
> mathematicians. Many programming systems (eg. data formats, languages,
> etc) are developed in an ad hoc and very practical way, that often
> serves adequately. However, this approach has regularly created
> situations where corner cases have significant problems, or particular
> expressions are simply not possible. One reason for the mathematical
> foundation of all of this is to avoid that kind of problem. Another
> issue is that OWL was developed by mathematicians who were
> specifically trying to create a language capable of expressing a
> particular set of mathematical properties. To build this on RDF meant
> that RDF needed very clear and formal semantics as well. So the entire
> system requires this horrible level of formalism that is very dry and
> often appears redundant, particularly from the perspective of english
> language. The thing is that those apparent redundancies are often
> required when using mathematical english.

Getting back to the case of sparql/docs/http-rdf-update/  ... :-)


>> Or take POST.  As far as HTTP is concerned a POST requests that the origin
>> server accept the entity enclosed in the request as a new subordinate of the
>> resource identified by the Request-URI in the Request-Line, and the URI in a
>> POST request identifies the resource that will handle the enclosed
>> entity.  Period.

RFC 2616 says that POST covers functions for sveral things - the last in 
the list is "Extending a database through an append operation." so this 
isn't a SPARQL-ism.

>>   Now, it might make sense to
>> provide some explanation of what "subordinate of the resource identified by
>> the Request-URI" means when the resources involved are RDF Graphs; but that
>> should be handled by an informal, informative NOTE.
>> All in all, it seems to me it would be better to call the thing "SPARQL
>> Application Protocol" or the like, and replace all the stuff about the
>> meanings of the HTTP methods by a simple reference to RFD2616.
>
> Well section 4 (the one on graph naming) is obviously required, and I
> think you're in agreement there. While I do see an argument for
> section 5 (describing the actions of HTTP verbs) being handled
> implicitly, I believe there would be too much ambiguity if it were
> done that way.
>
> As I mentioned earlier, there are a lot of really poor REST
> implementations out there where the authors just didn't understand
> that they were supposed to be acting on resources, and accidentally
> went off in the direction of RPC instead. Also, there may be some
> alternative interpretations of some operations. For instance, because
> RDF is both monotonic and has the open-world assumption, some
> implementors may think it valid for PUT to simply insert the contents
> of a graph additively, rather than replacing the existing graph. In
> many other contexts this would be wrong, but the monotonic and open
> world assumptions of RDF open this question up to debate.
>
> Finally, there is a lot of precedent for redundantly explaining
> concepts from foreign documents. This allows the reader to see exactly
> what the author had in mind for this particular context (in case of
> ambiguity) and also operates as a convenience so that the reader does
> not have to try to correlate various sources in order to understand a
> single document. Of course, this runs the risk of conflicting
> information, but I don't believe this has happened here.

Yes - there's value in publishing a doc to put the ideas firmly into the 
semweb domain.

>> Actually I'd
>> go further and drop the reference to SPARQL, and just call it something like
>> "RDF Resource Management Protocols".
>
> I get your point, but remember that the "P" in SPARQL stands for
> "Protocol". The document is about a protocol, so it gets published as
> part of the SPARQL spec.

I don't like the use of "Management" because I think a useful aspect is 
GET which isn't very management-y.  "management" to me suggests changes 
that involve changes in the store but not directly sending and receiving 
data.

The first working group was called the "RDF Data Access Working Group" 
(DAWG).

	Andy



More information about the Mulgara-dev mailing list