incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <>
Subject Re: How to name things with URIs
Date Tue, 17 May 2011 19:47:57 GMT
On Mon, May 16, 2011 at 11:20 AM, Henry Story <>wrote:

> Well perhaps it is at the wrong layer then. Perhaps a WebProxy, being at
> the web layer needs to know the name of the service it is running as. Please
> read through the following  reasoning carefully before replying.
> Consider that the API you are developing has the following method
>     def getGraph(name: UriRef)
> If the WebProxy services is called like this:
> wp.getGraph("".uri)
> Then it certainly would be very useful for the proxy service to know that
> is the local machine, and that it does not need to do an httpS
> GET to discover the graph.
Indeed doing a GET request might be useful. This is the case when a document
encoding RDF is available as a static resource (e.g. uploaded the same ways
as an image)

> A use case can help illustrate this. Imagine a zz service looks at a foaf
> file that contains a reference to <> It
> sends the request to the cache proxy to fetch the file so that it can find
> out more about that resource. What is it? A fish, a mineral, a human, or an
> ontology?  So it goes to the web proxy and calls it above. If your proxy
> looks in its
>    urn:x-localinstance:/cache/
> namespace it won't find a reference to our URL above. So it will do a GET
> on the web, find it,
> and place it in
>    urn:x-localinstance:/cache/
> Here I'm not following you, you said

1. is the local machine
2. the webproxy is accessed
3. after dereferencing the resource a graph is added to the cache

2 implies that the graph is not available locally as storage.web is only
accessed when no other storage provider is available, yet 3 implies that the
resource could successfully be dereferenced. This would only be the case
when the the URI names a resource that is not primarily a graph (as I
described above with the static resource).

> Now imagine I then update my profile. The next time my zz
> instance will go and look in the proxy it will find the above urn and look
> up the information there. Not only will we now have the information twice in
> the database, we will end up getting out of date information for our own
> data!
Typically a profile is served from a graph named with the uri of the
profile, so once this mgraph has been created storage.web will not be used
anymore for a resource with that name.

>   So interestingly this suggests that local data be placed in the store, in
> a graph that corresponds to the name of the graph at which people from
> across the web would fetch it at.

I agree with that, the emphasis is on "local data".

> Because then one won't need to do any special conversion when searching for
> data that is local. (Ie: public data about me should be placed in a graph
> named )
yes. this is implemented like that (I think you didn't change that)

>   OR  BETTER: all local data should be stored in the local store with
> *relative* URIs - of which your urn:x-localinstance is a hack to work with
> triple stores that don't come with relative URI support - and these
> *relative* uris should when transformed to global URIs be the URIs of what
> an external user would GET when making a request on that graph. Ie: my local
> public profile should be in the graph
>   /user/admin
> which is internally written out as
>   urn:x-localinstance:/user/admin
>   This gives us a simple but very powerful criteria to test URIs - which is
> what this thread is about: "How to name things with URIs".
>   - local graphs should be named by how they are accessible remotely (even
> if they only use relative URIs)
>   - remote cache graphs - ie graphs that pretend to only store what is said
> remotely - should (when public) store the data at the graph of the remote
> URL.
I think clerezza application should access all graphs the same way. For a
WebId profile this is the uri of the profile, most application need not care
if a user is local or not.

not sure what you mean by "when public", to access a graph one needs the
respective permission, the graphs in /cache should generally not be
accessible by users (i.e. not directly, only indirectly via the caching
storage provider, but then they see nothing about the /cache-uri)

>   Now: this is where your view and mine can converge. If the local Clerezza
> triple store republishes remote URLs, then those will have to be placed in
> the store at a local, relative
> URL, eg urn:x-localinstance:/cache, because at this point people will be
> able to point to the publishing zz instance to make the claims made by the
> remote graph.
What do you mean by republishing?

>   Though instead of doing that I would rather suggest using the HTTP Proxy
> mechanisms, and develop a Proxy  layer for each zz instance, as I think that
> avoids taking responsibility - other than the responsibility of being a good
> proxy - for what others say. (see slide 37 of my presentation "Philosophy
> and the Social Web"
> )
>   NEVERTHELESS it is then still true that the WebProxy needs to know the
> URIs of the local machine if it is going to function correctly, since it
> needs to know when it does not need to make an HTTP connection but can
> either look at the graph directly or make a request to the correct jax-rs
> method
I disagree. TcManager is a client-api. If gives you the possibility to get
triple collections by their name, with storage.web the triple-collections
you can get include any rdf document on the web. The browser you use on your machine needs not know that requests to go
to the local host, the smae goes for TcManager.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message