W3C home > Mailing lists > Public > uri@w3.org > August 2011

Re: Fwd: Re: Document fragment vocabulary

From: Erik Wilde <dret@berkeley.edu>
Date: Tue, 16 Aug 2011 13:49:48 +0200
Message-ID: <4E4A595C.4080702@berkeley.edu>
To: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
CC: uri@w3.org
hello sebastian.

> Another problem, we have is that the fragment id is not sent to the
> server. Did this ever play a practical role up to now? For Linked Data
> it can be cumbersome: Let's say you have a 200 MB text file, with
> average 3 annotations per line (200,000 lines, 600,000 triples ).
> Somebody attached an annotation on line 20000:
> <http://example.com/text.txt#line=20000> my:comment "Please remove this
> line. It is so negative!" .
> When making a query with RDF/XML Accept Header. You would always need to
> retrieve all annotations for all lines.
> Then after transferring the 900k triples, the client would throw away
> all other triples, except the one for this line.

the fact that fragment identifiers are client-side only is something 
that it pretty deeply engrained in web architecture. interactions on the 
web are based on resources, and if you're unhappy with interaction 
granularity (as you're indicating above), then this does not necessarily 
mean that you have to change web architecture, but instead that you may 
have a problem with your resource model. if you want interactions to be 
finer grained, then identify and build interactions around those 
finer-grained resources. linking can help you to find links from 
coarse-grained to fine-grained and vice versa, if you model it in a way 
where there are possible interactions with both finer and more coarsely 
grained resources.

speaking from the REST perspective, i think there's still very 
interesting and pretty much unexplored territory there. the question is 
how to come up with general RESTful models of how a service can expose 
resources at varying levels of granularity. but this is not so much a 
URI issue than more something that probably could be solved by a RESTful 
design pattern.

(as a side note: if you want to change resources in a diff-like way, you 
may want to look at the HTTP PATCH method, which allows you to request 
that a resource should be changed in a certain way.)

cheers,

erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-6432253 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |
Received on Tuesday, 16 August 2011 11:49:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:15 UTC