Re: Indirect Graph Identification

On Friday 9. December 2011 22.06.42 Chime Ogbuji wrote:
> <NonWGParticipantOpinion>
> 
> See comments line. I'm not sure if you intended this as a direct comment to
> document the document you refer to. In either case, my response is intended
> to make this thread constructive.

Yes, thank you! I was trying to refrain from a full discussion of the REST 
constraints relative to the specification, as I don't think that will help it 
forward. I think that the basic idea is sound and important, but there are 
specifics that I think would be harmful, and I was trying to avoid another 
round of "deciphering Roy", but oh well...

> On Friday, December 9, 2011 at 7:42 AM, Kjetil Kjernsmo wrote:
> > In my opinion, what makes this non-RESTful (RESTless?) is that the
> > Request-URI is different from the (embedded) graph URI.
> 
> I'm not sure what you mean by 'non-RESTful' or RESTless. REST is an
> architectural paradigm that constrains the problem of hypermedia
> applications in specific ways. Are you saying that a particular constraint
> is being broken?

Yes, I believe the HATEOAS constraint is broken, but the main problem isn't 
that constraints are clearly broken, the main problem is that it is not clear 
at all how I should evaluate the specification with respect to the REST 
constraints, especially in light of that it figures so prominently in the 
Abstract of the text.

The requirements from HATEOAS is perhaps not so easily made out from the 
dissertation, but he has elaborated on it here: 
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
So, the main problem isn't that the spec breaks HATEOAS, the main problem is 
that it doesn't say how it meets this constraint. For an explicitly RESTful 
protocol, this is a big shortcoming.

Now, I'm not saying that it should be fixed, as I think that the direct 
identification part of it satisfies HATEOAS, when used with Linked Data, but 
that we need to understand more of the practical implications, but that's 
something that should be undertaken outside of the SPARQL WG, it should not 
hold up the work any further.

The indirect identification part however, I'm pretty sure breaks HATEOAS. 
HATEOAS implies that you shouldn't define anything in the URI, that's out-of-
band information. It should be entirely driven by hypertext, i.e., it is the 
RDF that drives interaction (there's some ancient wisdom out there that says 
that if you feel inclined to use a verb or "service" in your URI, you're not 
doing REST, a service is seldom a resource in REST {{citation needed}} :-) ).


> You should be specific about which one in order to justify
> why you think downstream applications are negatively impacted by the
> ability to manipulate < .. insert your favorite name that describes the
> referent of or what is identified by an RDF graph URI and doesn't offend
> any particular sensibility ..> 

:-)

> that don't have a web presence. Do, you
> agree that 1) situations like this will arise in practice 2) it is useful
> to manipulate such "content"? 

Yes, certainly, but that people could use any URI for them.

> > So, there's a graph http://example.org/foo. We both make a copy of it
> > and
> > stuff it into our public endpoints with the same URI. Then, we use the
> > Graph Store protocol to manipulate these graphs using indirect graph
> > manipulation. Now, there are three different resources with the same
> > URI.
> 
> No.
> There is the a) the 'content' of the RDF graph whose URI is ex:foo and the
> various *distinct* N endpoint manipulation URIs, each which can be used
> with a web agent and uses the query component as described RFC 3986.

OK, lets be more concrete to see if I have completely misunderstood it:

There is a graph at ex:foo, containing the following statements:

</data/bar> a ex:Something;
               dc:title "Bar".

I insert that into my public endpoint using

PUT /rdf-graphs/service?graph=http://example.org/foo HTTP/1.1
Host: my.host.com
[snip further headers and above payload]

If I launch a SPARQL query on the corresponding query endpoint of either the 
original host or my own endpoint, say:

SELECT ?uri FROM <http://example.org/foo> WHERE { ?uri a ex:Something }

In both cases, will get the same result, right?

But then, I decide to add more data to my public endpoint:

POST /rdf-graphs/service?graph=http://example.org/foo HTTP/1.1
Host: my.host.com
Content-Type: text/turte

</data/baz> a ex:Something .

Now, 

SELECT ?uri FROM <http://example.org/foo> WHERE { ?uri a ex:Something }

will yield different results depending on which SPARQL query endpoint I use, 
right?    

That's the problem I want to avoid! If J. Random Hacker comes along with his 
agent, which automatically roams different SPARQL endpoints to satisfy the 
federated query (using an extended SPARQL federation implementation) he's been 
asking, this will cause some troublesome problems.    

The thing I'm trying to advocate is that this has a very straightforward 
solution if the indirect indentification is dropped. This would mean that I'm 
not doing 
PUT /rdf-graphs/service?graph=http://example.org/foo HTTP/1.1
on my host, I'm doing:
PUT /rdf-graphs/my-copies/example.org/foo HTTP/1.1

(or any other URI I find useful)

and then my query is 
SELECT ?uri FROM <http://my.host.com/example.org/foo> 
WHERE  { ?uri a ex:Something }

I could also add a statement into my RDF about the copy, thus making it far 
more likely that it will satisfy HATEOAS. 

This is a simpler solution as it trims a lot from the specification, as far as 
I can see, it satisfies the use cases people have forwarded, it is more likely 
to be RESTful and it avoids the above problems, and makes it more predictable 
what a query endpoint will return.

If I'm wrong in assuming that the query above will yield a different, I would 
of course withdraw that part of the comment. I still believe the spec violates 
the HATEOAS constraint due to the specification of the "graph" and "default" 
query components, but it would ease my worries somewhat.

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Ph.D. Research Fellow, Semantic Web
Department of Informatics, University of Oslo
kjekje@ifi.uio.no

Received on Monday, 12 December 2011 11:31:02 UTC