incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <reto.bachm...@trialox.org>
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 <henry.story@bblfish.net>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("https://bblfish.net/user/admin/".uri)
>
> Then it certainly would be very useful for the proxy service to know that
> bblfish.net 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 <https://bblfish.net/user/admin/#me> 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/https://bblfish.net/user/admin/
>
> Here I'm not following you, you said

1. bblfish.net 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 bblfish.net 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 https://bblfish.net/user/admin/ )
>
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"
> http://www.slideshare.net/bblfish/philosophy-and-the-social-web-5583083 )
>
>   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
bblfish.net machine needs not know that requests to http://bblfish.net/ go
to the local host, the smae goes for TcManager.

Reto

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