Re: URI-Triples: RDF serialization for use in query strings

Hi Benja,

Your approach to syntax make sense, and this is definitely worthwhile
work. I'm not sure it's worth putting much weight on legibility of the
URI strings, as the encoding make them pretty unreadable whatever you
do. But being a short step away from readability (using XSLT
formatting where XML data is available, or more simply code*). What I
don't get from your examples is the intended behaviour of the service
(for GET and POST). In other words, if you're doing a GET and passing
a bunch of statements, what are you asking the server for?  (aside -
might the common 256 character limit on GETs be a problem?).

begin:rambling
We do need some relatively standardized ways of passing RDF and RDF
queries around  (RESTful and SOAPy for starters). It should be easy
for a developer to do ASK and TELL performatives (with error handling
support) on the Semantic Web. The calls might be addressing
triplestores behind a Web server, but the behaviour should be
consistent with what's available for static Web pages. I've not really
been following the progress of DAWG, but I hope a RESTful HTTP
approach to inter-agent comms would be next on the list after SPARQL -
the use cases should fall like dominos.

There are a few RDF APIs around (e.g. Joseki's WebAPI), and the SPARQL
Protocol looks like it'll be very useful. But there doesn't seem to be
much cohesion between the approaches, still nothing you could call The
RDF Protocol. Ok, it's probably a situation where standards based on
implemented ad hoc specs might be preferable to up-front WG
recommendation. But maybe it's time for the DAWG to pick this up and
do some combination of the various approaches and a little unnatural
selection.

One aspect that's bugged me whenever I've looked around this stuff  is
Patrick Stickler's hobby horse, the URIQA operations.I really don't
know whether he's right about there being a need for new HTTP methods
(MGET etc). But  some well-known approach is needed to query a service
rdf:about a resource, especially the one in the request URI, using the
common methods.
end:rambling

Something that might also be worth taking into consideration is how
reliable messaging might be done on top of the basic protocol(s). Bill
deHora's HTTPLR [1] looks like it might be a good starting point -
coincidentally he's just done an update, his notes from today [2] are
worth a read.

Cheers,
Danny.

[1] http://www.dehora.net/doc/httplr/draft-httplr-01.html
[2] http://www.dehora.net/journal/2005/03/httplr_draft01_published_some_background_some_futures.html

*
class URIEncoder:
    def __init__(self):
        self.chars_codes = {"%":"%25",
                    " ":"%20",
                    "~":"%7E",
                    "/":"%2F",
                    "=":"%3D",
                    "&":"%26",
                    "+":"%2B"}
        self.codes_chars =  {"%2B":"+",
                             "%26":"&",
                             "%3D":"=",
                             "%2F":"/",
                             "%7E":"~",
                             "%20":" ",
                             "%25":"%"}
                             

    def encode_uri(self, uri):
        for char in self.chars_codes:
            print char +" " + self.chars_codes[char]
            uri = uri.replace(char, self.chars_codes[char])
        return uri

    def decode_uri(self, uri):
        for char in self.codes_chars:
            uri = uri.replace(char, self.codes_chars[char])
        return uri
-- 

http://dannyayers.com

Received on Monday, 14 March 2005 16:02:56 UTC