You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by Reto Bachmann-Gmuer <re...@apache.org> on 2011/05/10 14:44:26 UTC
How to name things with URIs
Hello
We do not currently have a coherent naming scheme for things in clerezza:
Graphs are named like
http://tpf.localhost/tbox.graph
or http://zz.localhost/web-resources.graph
local resources available on all virtual hosts are named like
urn:x-allhosts:/style/images/panel/tab-button-default.png
additionally we have singleton bnodes like [ a <
http://clerezza.org/2009/08/platform#Instance>]
These resources have in common that they are relative to the local instance.
This is similar to the special hostname "localhost". However as on one hand
multiple instances can run on the same host and on the other hand
localhost:8080 is the typical uri-authority section for development
instances using localhost as authority seems incorrect.
I'd suggest to generalize the urn:x-allhosts-approach and use
urn:x-localinstance, when shown to the ouside world these URIs should
generally be replaces with the protocol and host that was used to access the
Clerezza instance.
For the user graphs I suggest the following naming:
urn:x-localinstance:/user/<user-id>/public: the information the user makes
public to anyone who can read from the content graph
urn:x-localinstance:/user/<user-id>/private: the information only the user,
admins and apps running with full priviledges can access
urn:x-localinstance:/user/<user-id>/friends: the information the user and
her friends may read
urn:x-localinstance:/user/<user-id>/restricted-[1-n]: information owned by
the user with some custom access-configuration
The user-id for remote user is currently like:
https___farewellutopia.com_user_me_profile_me, typically a user that wants
to log-in with a username would like to change this. We might want to give
user an immutable uid used in the names of the user-graphs and a login-name
the user can change herself.
For cached graphs I suggest to have uirs like:
urn:x-localinstance:/cache/<remote-uri>
Looking at section 3.3 of rfc3986 it seems no special encoding ot
<remote-uri> is needed, if I understand it correctly a colons and
consecutive slashes are only forbidden in uris without scheme. Maybe we
should encode ? and # for the uri to be more easily usable.
Cheers,
Reto
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
Perhaps the better thing to do is to think of this in terms of an API
Let's imagine that UriRef allows for relative URIs. This would be really nice,
as it would mean that code in rdf ssp or jsr311 would not need to know where
it was going to be placed in order to make statements.
So I would like to be able to write code with
("/user/"+uname+"/#me").uri a FOAF.Person
without having to know what the server this was being served on.
Also the cache I would like to just do
val andreiGN = cache.fetch("http://fcns.eu/people/andrei/card#me")
Perhaps later we can add methods such as
cache.fetchAs(joe,"http://fcns.eu/people/andrei/card#me")
because joe has more rights. A bit like the Java security architecture
subject.doAs(...)
and then even have
andreiGN FOAF.knows ("/user/"+uname+"/#me").uri
Then there is the question what the graphs are named.
But could that not be just made into an interface for relative graphs to local ones? One
implementation could call do it the simple way I propose. Another the simple way reto
proposes, and then a third complex way may in fact place all the information of when something
was fetched and by whome and put that in a graph which it queries before what returning what
is perhaps in the end just a bnode for the graph name.
Henry
On 13 May 2011, at 16:11, Henry Story wrote:
>
> On 13 May 2011, at 16:07, Reto Bachmann-Gmür wrote:
>
>> > Well I did suggest an alternative in
>> >
>> > https://issues.apache.org/jira/browse/CLEREZZA-489
>> >
>> > and in fact that is what the WebProxy implements - I think.
>> >
>> > And that is in short that remote graphs use the name of the remote
>> > resource from which they come, and local graphs have local names.
>>
>> I argues why i strongly believe the local cache version must have a distint name than the remote graph. I agree the the original .cache suffix was not at all ideal, but i disagree with your change of just naming it by the uri of the remote graph.
>
> Sorry I must have missed that argument. Where do you argue that a local cache version must have a distinct name?
>
> Henry
>
>
>
> Social Web Architect
> http://bblfish.net/
>
Social Web Architect
http://bblfish.net/
Re: the metagraph -- Re: How to name things with URIs
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
On Mon, May 16, 2011 at 10:32 AM, Henry Story <he...@bblfish.net> wrote:
> ok, so the next thing to build then is this metadata information graph.
> What shall we call it? (Now here one of those zz urls is of course perfectly
> fine!)
What about urn:x-localinstance:/rdf/storage/web/cache-status
Cheers,
Reto
the metagraph -- Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 16 May 2011, at 08:06, Reto Bachmann-Gmuer wrote:
> On Sun, May 15, 2011 at 7:38 PM, Henry Story <he...@bblfish.net> wrote:
>>
>> [snip]
>> But there are some things I was looking at that may be important to consider.
>>
>> In the WebProxy I do return a Resource object that comes with information about the graph.
>> So it is a bit more than a graph node. It is a graph containing a graph node: a GraphNodeGraph
>> perhaps; Metadata about a resource, including the graph. I was thinking this would be useful
>> to be able to work out what an issue with a remote graph was, if one should force fetch it again...
> Your proposal introduced new interfaces which are not yet actually
> used,
Well I was going to use them for work in helping debug WebID, pingback and
other protocols.
> this is a typical case for over architecture, lets do the
> simplest thing first.
What is simplest is discovered through a process; it is not given ahead
of time. For example it took a first implementation of a simple caching
system, for people here to see the use of it - demonstrated with WebID,
pingback, and foaf - to see that this should be tied into the more general
structure of zz, which led to this refactoring, and so to the simplification.
I am not sure I would have gotten a lot of attention and interest in the
simplification before showing the value of the system. And indeed not knowing
Clerezza that well, I would probably not have been the right person to make the
correct simplification. It is the usefulness of the service that makes it
worthwhile investing the energy into the simplification.
> The obvious next step is to have an graph with
> meta information about the cached graphs. Then we might see that we
> can simplify client code by returning an object holding both the graph
> and the meta-information. But by introducing this indirection right
> away you make client code more complicated.
Only because you have now seen the tie in with TcManager
which is a refactoring. Initially it was not that much more complicated, since
one gets these pieces of information in the first HTTP GET.
But I agree we can and should have a graph of metadata about the way the
resources were fetched. They should probably use the Tabulator ontology, since that
is already used in a live project. I mentioned this right at the beginning of the
project, and did not develop it more immediately because I wanted to wait for
this kind of refactoring proposition to come along.
This metadata where graphs were found, the redirects, the e-tags, etc, are all
going to be very important to a good web proxy service, which I think is in fact
going to end up being one of the most important parts of zz.
>
>> It is something that can be very useful to know: a WebID in your foaf file is no longer accessible,
>> should it be removed from the foaf? A resource was last fetched a week ago, but it is important in the current transaction, one should perhaps fetch it again: the information may be out of date.
>> Two graphs content clash, which one is freshest? Who said what? What was the previous version of this graph? (Oh, it's completely different?! Mhh...). Which application created it? (We deleted that did we not? Perhaps it's graphs should go too)
>>
>> I was hoping to explore that a bit further to see where it leads to. But it will of course also
>> make sense for a TcProvider too. What do you think?
> This certainly all makes sense, yet there are and always will be
> client that don't need to care about this complexity so an api
> optimized for them need to be provided in any case. So considering
> that the implementation wasn't actually offering this additional
> information it doesn't make sense to make the API preemptively more
> complicated.
>
> Lets build clerezza like a building, have a modest goal for the next
> step, place a brick, make sure its solid close the issue and proceed.
ok, so the next thing to build then is this metadata information graph.
What shall we call it? (Now here one of those zz urls is of course perfectly
fine!)
Re: How to name things with URIs
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
On Mon, May 16, 2011 at 11:20 AM, Henry Story <he...@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
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
Where we propose an initial criterion to answering the question this thread is asking:
"How to name things with URIs".
>> [snip]
>> On 15 May 2011, at 12:11, Reto Bachmann-Gmuer wrote:
>>> Henry Story Wrote:
>>>> [snip]
>>>> But here is a quick question: why not simply make the ProxyTcProvider a higher priority than the pure local one?
>>> We wouldn't know when to try to dereference a graph and when not.
>>
>> Any Resource that is not local, that can be dereferenced (http, https, ftp, ftps,...) (that is not on some blacklist) can be dereferenced.
>>
>> Any resources that are local (localhost domain, or the name of the current machine
>> is running on) should be passed to the next TcProvider.
> We don't know the names of the current machine, remember that we are
> operating on the rdf access layer (SCB) here. Unlike the WebId service
> this is not on the platform service.
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.
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/
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!
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. 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/ )
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.
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.
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
Re: How to name things with URIs
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
On Sun, May 15, 2011 at 7:38 PM, Henry Story <he...@bblfish.net> wrote:
>
> On 15 May 2011, at 12:11, Reto Bachmann-Gmuer wrote:
>
>> On Sun, May 15, 2011 at 11:28 AM, Henry Story <he...@bblfish.net> wrote:
>>> And we did boil things down to the question of why we need
>>>
>>> urn:x-localinstance:/cache/<remote-uri>
>>>
>>> rather than just
>>>
>>> <remote-uri>
>>>
>>> We both agree that either is an improvement over <remote-uri>.cache
>>
>> no, we just both agree that <remote-uri>.cache is ugly.
>
> You don't agree that this can lead to name clashes?
I absolutely agree with that.
>
> I presented the possibility of a foreign url being named
>
> http://amazon.com/books/on.cache
>
> For example.
Yes, I saw this argument and completely agree with it, its just not an
argument against my position which is consistent with your position as
far as I think this .cache uri needs to be changed.
>
> Is that perhaps not the most important role of URIs, to allow a global
> distributed naming system that does not have a problem with name clashes?
>
> So my point against .cache is that it is worse than ugly: it is broken.
I'm not defending .cache - in fact I want to change it, I just
disagree with you proxy implementation and with naming the cache copy
same as the source.
>
> Anyway urn:x-localinstance:/cache/<remote-uri> does not have that problem.
Exactly.
>
> The issue is what it brings that <remote-uri> alone does not.
>
>> But imho <remote-uri> isn't practicable (at least as long as we want to keep
>> this in the rdf.*-bundle set and not have this be part of platform.*).
>
> That is something you have not explained yet.
>
> What this is revealing is that the reason you are against what seems like the
> intuitively reasonable naming choice have to do with implementations decisions
> made in Clerezza and ones you were about to make (turning the cache into a
> TcProvider). Clarifying this does indeed help advance the debate, because
> I can now understand where you are coming from more clearly.
That's the advantage of speaking in code ;)
>
>>
>>> Ok, so this issue is occurring because you are refactoring WebProxy to be a
>>> TcProvider, which it was not originally. One can of course see the pull to
>>> making it a TcProvider, though perhaps the delete methods are not so useful
>>> there.
>> Virtual TcProvider typically don't implement these. I think we shall
>> have good reasons to extends the publi api. With my suggestion we
>> extend it by just one class, one public member and one enumeration.
>> With you proposal - after i reduced visibility of some members - there
>> are still 2 new public classes with 6 new public members and one
>> enumeration. For the public APIs change and extensions we accept into
>> trunk we should be more conservative than just for implementation,
>> especially for a core component like this Proxy.
>
> As I said, I see the pull to making it a TcProvider, ie to use the interface you
> use for accessing all graphs.
As graphs are named with globally unique identifier I really don't see
why a separate interface should be needed depending on their location.
>
> But there are some things I was looking at that may be important to consider.
>
> In the WebProxy I do return a Resource object that comes with information about the graph.
> So it is a bit more than a graph node. It is a graph containing a graph node: a GraphNodeGraph
> perhaps; Metadata about a resource, including the graph. I was thinking this would be useful
> to be able to work out what an issue with a remote graph was, if one should force fetch it again...
Your proposal introduced new interfaces which are not yet actually
used, this is a typical case for over architecture, lets do the
simplest thing first. The obvious next step is to have an graph with
meta information about the cached graphs. Then we might see that we
can simplify client code by returning an object holding both the graph
and the meta-information. But by introducing this indirection right
away you make client code more complicated.
> It is something that can be very useful to know: a WebID in your foaf file is no longer accessible,
> should it be removed from the foaf? A resource was last fetched a week ago, but it is important in the current transaction, one should perhaps fetch it again: the information may be out of date.
> Two graphs content clash, which one is freshest? Who said what? What was the previous version of this graph? (Oh, it's completely different?! Mhh...). Which application created it? (We deleted that did we not? Perhaps it's graphs should go too)
>
> I was hoping to explore that a bit further to see where it leads to. But it will of course also
> make sense for a TcProvider too. What do you think?
This certainly all makes sense, yet there are and always will be
client that don't need to care about this complexity so an api
optimized for them need to be provided in any case. So considering
that the implementation wasn't actually offering this additional
information it doesn't make sense to make the API preemptively more
complicated.
Lets build clerezza like a building, have a modest goal for the next
step, place a brick, make sure its solid close the issue and proceed.
>
> Compared to many other implementations of TcProvider this one has relatively few methods
> that throw a NotImplementedException: createMGraph, deleteTripleCollection and here
> it even makes sense to deleteTripleCollection . And it may even be possible to envisage it making
> sense to create one in the longer term....
The rdf.storage.web might support creating new remote graphs (e.g. via
http put) in future.
>
>>
>>>> So you're welcome to make suggestion on how it
>>>> should be different,
>>>
>>> I have not really had time to study all your local TcProviders, nor
>>> work out how a number can help anything distinguish between one TcProvider
>>> and another. I have to go right now - my sister is calling...
>>>
>>> But here is a quick question: why not simply make the ProxyTcProvider a higher priority than the
>>> pure local one?
>> We wouldn't know when to try to dereference a graph and when not.
>
> Any Resource that is not local, that can be dereferenced (http, https, ftp, ftps,...) (that is not on some blacklist) can be dereferenced.
>
> Any resources that are local (localhost domain, or the name of the current machine
> is running on) should be passed to the next TcProvider.
We don't know the names of the current machine, remember that we are
operating on the rdf access layer (SCB) here. Unlike the WebId service
this is not on the platform service.
>
> So my feeling here is that TcProviders should be arranged a bit like a Servlet Filter, each one does something, if it cannot do it, it passes it on to the next one in the stack. Then one can build stacks of Providers. (I have only looked at 3 or four implementations of TcProvider).
> (Perhaps a simple stack is too simple...)
Quite similar to what we have it seems. Anyway, if we encounter
problems with the current infrastructure we can discuss improvement.
But I think its perfectly possible to use for implementing the proxy
service. Unless for your wish of having the internal name of the cache
copy named the same way as the cached resource which is something I
think its a bad idea anyway (as argued in previous mails).
>
>> I propose to name our default graphs with localinstance-uris but it
>> shall still be possible to store a triplecollection with any name in
>> TcManager (again doing the least possible change to the behaviour of
>> the public api). Thus we wouldn't know for a graph named with a
>> dereferenceable uri if we should try to update it of if the local copy
>> is authoritative (and trying to update would generate a circle).
>
> Ok so what you want is in fact something you had not explained before.
> You want remote graphs that should not be fetched, say foaf, or owl to
> be at their namesepace in the TcManager.
> So the name of the foaf graph should
> be
>
> http://xmlns.com/foaf/0.1/ [ mhh foaf is a difficult one ]
>
> the cert graph should be named
>
> http://www.w3.org/ns/auth/cert#
>
> the owl graph should be named
>
> http://www.w3.org/2002/07/owl
>
> Anyway, these should be looked at carefully, because we can get good feedback from the semweb community on how those graphs should be called.
No, I didn't say that. I'm just saying that you can store any triple
collection with any valid UriRef as name with TcManager. This is just
as it is now and has been like this since there is TcManager. I see no
reason to change this now, my naming proposal was about conventions of
the platform and not about a change of functionality on the scb layer.
>
> Then all graphs that are fetched through the cache should be called
>
> urn:x-localinstance:/cache/<remote-uri>
This is the internal name of the cache copy, normal client do not
access this graph but they access <remote-uri>
>
> Because then you can have a simple fall through logic of TcManagers, where if it is not found in the first TcManager, the next WebProxy TcManager can fetch it.
Well, its more that the fact that it is not (easily) possible to make
a TcProvider when equivocally using <remote-uri> for the remote graph
and the cache copy shows that such an equivocation is bad.
Reto
>
> Is that it?
>
>>>
>>>> but without other proposal and without you
>>>> withdrawing the -1 I have to change it to
>>>> name.getUnicodeString+".cache" which was the last (silently) accepted
>>>> name. I think we both agree that localinstance is better than the
>>>> .cache proposal, so I urge you to revoke your vote.
>> Above you confirmed that you agree that
>> urn:x-localinstance:/cache/<remote-uri> is better than
>> <remote-uri>.cache so I don't understand why you're still vetoing this
>> change.
>
> This is a very important discussion I think. We are progressing.
>
> Henry
>
>
>>
>> Reto
>>
>>
>>>>
>>>> Cheers,
>>>> Reto
>>>>
>>>> On Sun, May 15, 2011 at 12:17 AM, Henry Story <he...@bblfish.net> wrote:
>>>>> I would like you first to read through the extensive mail I wrote, which took
>>>>> me some time to write, and think things through.
>>>>>
>>>>>
>>>>> Henry
>>>>>
>>>>> On 14 May 2011, at 22:37, Reto Bachmann-Gmuer wrote:
>>>>>
>>>>>> On Sat, May 14, 2011 at 7:54 PM, Henry Story <he...@bblfish.net> wrote:
>>>>>>> Btw, I suppose I should say that I am not massively against the suggestion
>>>>>>> you started this thread with. It is more than I am trying to explore this
>>>>>>> more carefully, because it is an important discussion that deserves careful
>>>>>>> thought.
>>>>>> The careful procedure is to have tiny little issues which when
>>>>>> resolved bring a tiny but undisputed improvement. Now with your
>>>>>> resolution of CLEREZZA-463 I'm having massive problems and even if you
>>>>>> think the status quo ante was fundamentally wrong I believe the
>>>>>> graph-renaming you did makes things worse.
>>>>>>
>>>>>> I know that CLEREZZA-463 contains many real improvement. But it also
>>>>>> introduce problems. And not just what you might consider a
>>>>>> philosophical problem that names denote extensionally different things
>>>>>> but also very practical ones.
>>>>>>
>>>>>> One major problem is the permission. We introduces
>>>>>> WebIdBasedPermissionProvider and one implementation
>>>>>> (UserGraphAcessPermissionProvider) used to provide readwrite access to
>>>>>> the profile graph. Now this no longer works because you changed the
>>>>>> names of graphs. Because of this and not because of a fundamentally
>>>>>> broken architecture before your patch applications that used to work.
>>>>>>
>>>>>> Your -1 was against urn:x-localinstance:/cache/<remote-uri>
>>>>>>
>>>>>> The status quo ante was
>>>>>>
>>>>>> cache graph: <web-profile-uri>.cache
>>>>>> profie-graph: <web-profile-uri>
>>>>>>
>>>>>> with the resolution of CLEREZZA-463 we have
>>>>>>
>>>>>> cache graph <web-profile-uri>
>>>>>> profile graphs for local users: <web-profile-uri>
>>>>>> profile graphs for remote users: <default-base-uri>/<web-profile-uri>
>>>>>>
>>>>>> you did change some names, probably just because of inconsistent
>>>>>> changes things broke (UserGraphAcessPermissionProvider seems pointless
>>>>>> right now). I don't want to
>>>>>>
>>>>>> and such that because of the renaming of graphs the
>>>>>> UserGraphAcessPermissionProvider
>>>>>>
>>>>>> - The user has no longer the right to write to its own graph
>>>>>> - Because the user graphs that is now (with your resolution of
>>>>>> CLEREZZA-463) named like
>>>>>> <http://localhost:8080/user/https://farewellutopia.com/user/me/profile>
>>>>>>
>>>>>> In my opinion to changed a suboptimal solution against quite a mess,
>>>>>> now you argue against my solution to tidy things up because you are
>>>>>> afraid of having a mess in one year.
>>>>>>
>>>>>> So please either accept my proposal which started this thread as
>>>>>> something that is better than the status quo (i.e. retract your -1 so
>>>>>> I can finally go back coding) or make a concrete proposal on how to
>>>>>> name the different entities I've been suggesting names for or else
>>>>>> revert the changes for CLEREZZA-463 (so that applications that used to
>>>>>> work work again and we can start a proper development with little
>>>>>> issues and patches that represent undisputed improvements.
>>>>>>
>>>>>>
>>>>>> ==== what I consider important and relevant to current development
>>>>>> ends here ====
>>>>>>
>>>>>>>
>>>>>>> On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
>>>>>>>
>>>>>>>> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>>>>>>>>> Reto wrote:
>>>>>>>>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>>>>>>>>> that I'm stating rather than arguing.
>>>>>>>>> :-)
>>>>>>>>>> The argument: they are different thing, both intensionally (cache and
>>>>>>>>>> source) as in many case extensionally (triples may differ).
>>>>>>>>>
>>>>>>>>> in that sense I agree.
>>>>>>>>> But then the other point I made is also true, and that is that different
>>>>>>>>> users may get different
>>>>>>>>> graphs back for the same remote resource. In fact those users may be the
>>>>>>>>> same user at different times. Since those are all different graphs by your
>>>>>>>>> definition above one should also give them different names.
>>>>>>>> We do not have support for this yet and I think its a feature
>>>>>>>> increasing complexity massively.
>>>>>>>
>>>>>>> You are dealing with an architectural problem which cannot just be dealt
>>>>>>> with in stages. You need to look at the problem as a whole, or you will
>>>>>>> just end up with the problem we are having right now. It is better to get this
>>>>>>> issue cleared up now, than have a mess of graph names in one year, when a lot of
>>>>>>> applications depend on this.
>>>>>> This kind of against agile mantras and it seems to contrast very
>>>>>> strongly to what you just did: you changed the names and now want a
>>>>>> scientific study to change them again to solve the problems your
>>>>>> namechange introduced.
>>>>>>
>>>>>>>
>>>>>>> In any case it's not increasing anything massively, it is the logical
>>>>>>> continuation of your point above.
>>>>>> If you propose a patch which changes names and deliver good arguments
>>>>>> why the new names are massively better and support future usecases
>>>>>> without any disadvantage for addressing the current usecases than I'm
>>>>>> sure this gets accepted, what you did is mix-in this namechange in a
>>>>>> whole bunch of patches.
>>>>>>
>>>>>>>
>>>>>>> Your argument was:
>>>>>>>
>>>>>>> "they [the remote and the locally fetched graph] are different thing, both
>>>>>>> intensionally (cache and source) as in many case extensionally (triples may differ)."
>>>>>>>
>>>>>>> And so it follows that graphs sent at different times may also differ
>>>>>>> extensionally and should have different names too.
>>>>>>
>>>>>> No, we are talking about MGraphs here. I know transtemporal identity
>>>>>> is a hard problem philosophically yet in practice we have quite strong
>>>>>> intuition on what we consider to be the same thing over time. the
>>>>>> google website remains the google website even if they change the
>>>>>> design, same goes for the wikipedia page about google it remains the
>>>>>> wikipedia site about google (with the same URI) even after it was
>>>>>> changed, one never becomes the other.
>>>>>>
>>>>>>>
>>>>>>> You can't have it both ways, argue on intentionality for different names and then
>>>>>>> refuse to see that temporally different graphs would also then need different names.
>>>>>> I was talking about intensionality. Two terms have a same intension
>>>>>> only is in the same universe of evaluation and at the same point in
>>>>>> time they have the same extension.
>>>>>>
>>>>>>>
>>>>>>> ( Btw. there are good arguments that intentionally the local graph if it is a cache
>>>>>>> does not differ from the remote one. In any case if you pursue this too far you will
>>>>>>> find that you can never name any remote thing. )
>>>>>>>
>>>>>>>> I don't think that clerezza-490 need to be resolved urgently, but anyway we
>>>>>>>> should proceed issue by issue, and the best resolution of an issue is a minimal
>>>>>>>> resolution not one that tries to foresee and future issues.
>>>>>>>
>>>>>>> I tend to see logical consequences of an argument as being contained in the argument,
>>>>>>> and not being future issues that can be looked at later as somehow being distinct.
>>>>>> yes, but:
>>>>>> 1. analysing till the very bottom inevitably leads to paralysis.
>>>>>> 2. this inconsistent with your intuition based named change without discussion
>>>>>> 3. We have problems needing a fix (only to be as good as before your
>>>>>> patches) and you're not making a concrete proposal
>>>>>>
>>>>>>>
>>>>>>> Clerezza-490 that deals with different ways the server can present itself to other
>>>>>>> servers, is not of course something that needs to be implemented immediately. But it
>>>>>>> would be good that the naming solution we come up with can be extended to that case
>>>>>>> and to the temporal case.
>>>>>>>
>>>>>>> So I am invoking Clerezza-490 as something to help test the naming ideas being put
>>>>>>> forward here. This is a logical test if you will.
>>>>>> see above
>>>>>>
>>>>>>>
>>>>>>>>> So local graph naming schemes should take that into account, which is why I
>>>>>>>>> suggest that we have an API that can allow for extensibility here.
>>>>>>>> We have currently things and we are naming them badly.
>>>>>>>>
>>>>>>>> Prior to you r webproxy we had:
>>>>>>>> <webid-profile-url>.cache as name for the cache of the webprofile
>>>>>>>> and
>>>>>>>> <webid-profile-url> as uri for triples the user generated locally,
>>>>>>>> this can be seen as extensions to the remote profile with information
>>>>>>>> (like preferred language) that happen not to be in the remote profile
>>>>>>>>
>>>>>>>> which was consistent with local users who only had
>>>>>>>> <webid-profile-url> for the triples they control which include both
>>>>>>>> the regular profile as well
>>>>>>>
>>>>>>> yes, and both of those were not good solutions.
>>>>>>> The .cache solution is bound to create a problem if someone remotely has
>>>>>>> a URI named http://some.example/resource.cache
>>>>>>>
>>>>>>> It is bound to lead to nasty name clashes, with the same URI naming two different things.
>>>>>> right, I'm admitting it wasn't ideal - but I preffere the seldom
>>>>>> clashes to the ambiguity by design.
>>>>>>
>>>>>>>
>>>>>>> Remote URIs are named by remote resources, so it makes more sense to use the URI of the
>>>>>>> remote resource to name the graph of the remote resource. The remote resource was named
>>>>>>> by the owner of the resource. We should respect that.
>>>>>> <sarcasm>so we nshould not do caching, as the uri prefix http implies
>>>>>> a preferred method for retrieving the resource which is definitively
>>>>>> different than getting it out of a local tdb store</sarcasm>
>>>>>>
>>>>>>>
>>>>>>> If there are local additions to a remote graph, they should be given a local
>>>>>>> URI. There is nothing simpler than this solution it seems to me.
>>>>>>>
>>>>>>>>
>>>>>>>> Now <webid-profile-url> is the cache,
>>>>>>>
>>>>>>> You can look at it that way, or you can think of it as the name of the remote
>>>>>>> graph, with the contents being the cache of the remote graph.
>>>>>>>
>>>>>>> If you were to make the local graph available publicly, it would then of
>>>>>>> course need to have a local url tied into your namespace. Perhaps this is a good
>>>>>>> way to think of the distinction.
>>>>>>
>>>>>> I'm noty saying your proposal is absurd, but you introduced in a way
>>>>>> that breaks things an without discussion. now that I want to clean the
>>>>>> mess you start writing socio-philosophical essays
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> not sure where additional
>>>>>>>> triples added locally get stored, i.e. where triples added to
>>>>>>>> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
>>>>>>>
>>>>>>>
>>>>>>> They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
>>>>>>>
>>>>>>> So currently as an initial proposal I put them in
>>>>>> as a proposal ok, but you changed something that was working without
>>>>>> dissusing the consequences this e.g. for permissions.
>>>>>>
>>>>>> <snip/>
>>>>>>> Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
>>>>>>>
>>>>>>> A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
>>>>>>>
>>>>>>> By giving apps access to name spaces you can also make sure that there won't be any clashes.
>>>>>> there is nothing that prevent application from making there own graphs
>>>>>> for user information.
>>>>>>
>>>>>>>
>>>>>>> now, that could be a reason for having URIs like
>>>>>>>
>>>>>>> mvn:/dev.net/application1/?user=webid...
>>>>>>>
>>>>>>> But then you see that applications on different servers will have name clashes too if they
>>>>>>> ever merge their databases.
>>>>>>>
>>>>>>> The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
>>>>>>>
>>>>>>>> I'm not saying the old naming was perfect but it worked in a somehow
>>>>>>>> consistent fashion for local and remote users.
>>>>>>>
>>>>>>> It was very confusing to me at least, as I point out in CLEREZZA-489.
>>>>>>>
>>>>>>> And it furthermore is inconsistent with your point above that remote graphs are
>>>>>>> intentionally different from the local version.
>>>>>>>
>>>>>>>> Now my application taht used this feature is now longer working.
>>>>>>>
>>>>>>> Well that is the problem of having an initial system that is broken.
>>>>>>> It will be easy to fix this, and we should fix it well, not do a half job of it,
>>>>>>> because this is a distributed naming problem.
>>>>>> I'm tired. I've nothing against a concrete counter proposal against
>>>>>> the one that started the tread, e.g. saying: "we must give every
>>>>>> instance a unique-id and this should be part of the
>>>>>> x-localinstance-uri"
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> in Clerezza-489 I wrote that one could describe each graph like this in a
>>>>>>>>> special Cache graph perhaps.
>>>>>>>>> :g202323 a :Graph;
>>>>>>>>> = { ... };
>>>>>>>>> :fetchedFrom <https://remote.com/>;
>>>>>>>>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>>>>>>>>> :representation <file:/tmp/repr/202323>;
>>>>>>>>> :httpMeta [ etag "sdfsdfsddfs";
>>>>>>>>> validTo "2012...."^^xsd:dateTime;
>>>>>>>>> ... redirected info?
>>>>>>>>> ] .
>>>>>>>>>
>>>>>>>>> :g202324 a :Graph;
>>>>>>>>> = { ... };
>>>>>>>>> :fetchedFrom <https://remote.com/>;
>>>>>>>>> :fetchedBy <http://farewellutopia.com/reto#me>;
>>>>>>>>> :representation <file:/tmp/repr/202324>;
>>>>>>>>> :httpMeta [ etag "ddfsdfsddfd";
>>>>>>>>> validTo "2012...."^^xsd:dateTime;
>>>>>>>>> ... redirected info?
>>>>>>>>> ] .
>>>>>>>>
>>>>>>>> If we had barketing in RDF and our tooling would support it the the
>>>>>>>> above might be somehow topical, answer to the question "how to name
>>>>>>>> this?" "don't name it".
>>>>>>>
>>>>>>> The above is just a way of writing the contents of the graph and the metadata
>>>>>>> in the same file. That is what the
>>>>>>>
>>>>>>> :g202323 = { ... }
>>>>>>>
>>>>>>> is about. You don't need any special tools for that. If you use Jena to get the graph
>>>>>>> named above you would get the content of the brackets. The point is that the content
>>>>>>> from
>>>>>> Also in jena the graphs have a name, very profane sequence of
>>>>>> characters this discussion was about. So in clerezza of in jena in the
>>>>>> metadata graph you have a name instead of {...} and for this name you
>>>>>> will get {...} from the named graph store.
>>>>>>
>>>>>>>
>>>>>>> :fetchedFrom ..
>>>>>>> :fetchedBy ...
>>>>>>>
>>>>>>> is not in the g202323 graph, but in a graph metadata graph.
>>>>>> obviously
>>>>>>>
>>>>>>>> Please lets proceed issue by issue and make
>>>>>>>> sure every brick we place is really solid and separate this from
>>>>>>>> visionary long term stuff.
>>>>>>>
>>>>>>> Ok, I hope you see that I introduced nothing new there. It's just an
>>>>>>> n3 notation that makes it easy to write things out in an e-mail.
>>>>>> an n3 notaions that omits exactly what this discussion is about,
>>>>>> namely my nameing proposal and your -1 gainst it.
>>>>>>
>>>>>>>
>>>>>>> So please consider that point again in that light.
>>>>>>>
>>>>>>>>>
>>>>>>>>> Then this API could use information from this graph to and information from
>>>>>>>>> the user's request
>>>>>>>>> to find the correct local graph he wants.
>>>>>>>> Still the local graph would have a name, probably - but as I said its
>>>>>>>> irrelevant. Lets deal with the issues at hand, you changed the names
>>>>>>>> of graph (which I agree didn't have the best possible names) with
>>>>>>>> names that I think are worse, lets find something we can agree upon.
>>>>>>>> (otherwise, please roll back to the version with the orginal names
>>>>>>>> till we find a consensus).
>>>>>>>
>>>>>>> Well I don't think rolling back would improve anything. I think clearly
>>>>>>> this was an improvement. But I do think we can do better.
>>>>>> It a mixture between improvements and deterioration. following the
>>>>>> right process avoids the deterioations
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> So my thinking is that to reach consensus we can do this with an API, without
>>>>>>> deciding what precisely the names should be.
>>>>>> Stop: I disagree with your new names and we have problems because of
>>>>>> your name changes and now you dont want to decide about names?!
>>>>>>
>>>>>>> The best is just to lay out the
>>>>>>> requirements:
>>>>>>>
>>>>>>> 1. mapping from a remote URI to the URI understood by the local triple store
>>>>>>> and back. There should be no name clashes. It should be possible to easily extend
>>>>>>> to have agent views and temporal views.
>>>>>>>
>>>>>>> 2. method for applications to take hold of legitimate namespaces in such a way that
>>>>>>> a clash of names is not possible.
>>>>>>
>>>>>> If any proposal for changing names satisfies one of your criteria less
>>>>>> than the staus before the poposal your applying the argument to the
>>>>>> concrete proposal is welcome.
>>>>>>
>>>>>> Reto
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Henry
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Reto
>>>>>>>>
>>>>>>>>> Henry
>>>>>>>>> PS. Having said that one then may just wonder why local graphs should ever
>>>>>>>>> have anything other than
>>>>>>>>> local URLs, since every time someone made a copy of a local graph it would
>>>>>>>>> be different.
>>>>>>>
>>>>>>> Social Web Architect
>>>>>>> http://bblfish.net/
>>>>>>>
>>>>>>>
>>>>>
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>>
>>>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>
> Social Web Architect
> http://bblfish.net/
>
>
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 15 May 2011, at 19:38, Henry Story wrote:
>> Above you confirmed that you agree that
>> urn:x-localinstance:/cache/<remote-uri> is better than
>> <remote-uri>.cache so I don't understand why you're still vetoing this
>> change.
Ok to summarise your solution is better that the .cache solution.
Your TcManager hides things from the user.
So if <remote-uri> were the better solution then it should be possible to
move to it later. Your solution is safe.
If we can leave the issue open of if <remote-uri> is better then I remove the -1.
Henry
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 15 May 2011, at 12:11, Reto Bachmann-Gmuer wrote:
> On Sun, May 15, 2011 at 11:28 AM, Henry Story <he...@bblfish.net> wrote:
>> And we did boil things down to the question of why we need
>>
>> urn:x-localinstance:/cache/<remote-uri>
>>
>> rather than just
>>
>> <remote-uri>
>>
>> We both agree that either is an improvement over <remote-uri>.cache
>
> no, we just both agree that <remote-uri>.cache is ugly.
You don't agree that this can lead to name clashes?
I presented the possibility of a foreign url being named
http://amazon.com/books/on.cache
For example.
Is that perhaps not the most important role of URIs, to allow a global
distributed naming system that does not have a problem with name clashes?
So my point against .cache is that it is worse than ugly: it is broken.
Anyway urn:x-localinstance:/cache/<remote-uri> does not have that problem.
The issue is what it brings that <remote-uri> alone does not.
> But imho <remote-uri> isn't practicable (at least as long as we want to keep
> this in the rdf.*-bundle set and not have this be part of platform.*).
That is something you have not explained yet.
What this is revealing is that the reason you are against what seems like the
intuitively reasonable naming choice have to do with implementations decisions
made in Clerezza and ones you were about to make (turning the cache into a
TcProvider). Clarifying this does indeed help advance the debate, because
I can now understand where you are coming from more clearly.
>
>> Ok, so this issue is occurring because you are refactoring WebProxy to be a
>> TcProvider, which it was not originally. One can of course see the pull to
>> making it a TcProvider, though perhaps the delete methods are not so useful
>> there.
> Virtual TcProvider typically don't implement these. I think we shall
> have good reasons to extends the publi api. With my suggestion we
> extend it by just one class, one public member and one enumeration.
> With you proposal - after i reduced visibility of some members - there
> are still 2 new public classes with 6 new public members and one
> enumeration. For the public APIs change and extensions we accept into
> trunk we should be more conservative than just for implementation,
> especially for a core component like this Proxy.
As I said, I see the pull to making it a TcProvider, ie to use the interface you
use for accessing all graphs.
But there are some things I was looking at that may be important to consider.
In the WebProxy I do return a Resource object that comes with information about the graph.
So it is a bit more than a graph node. It is a graph containing a graph node: a GraphNodeGraph
perhaps; Metadata about a resource, including the graph. I was thinking this would be useful
to be able to work out what an issue with a remote graph was, if one should force fetch it again...
It is something that can be very useful to know: a WebID in your foaf file is no longer accessible,
should it be removed from the foaf? A resource was last fetched a week ago, but it is important in the current transaction, one should perhaps fetch it again: the information may be out of date.
Two graphs content clash, which one is freshest? Who said what? What was the previous version of this graph? (Oh, it's completely different?! Mhh...). Which application created it? (We deleted that did we not? Perhaps it's graphs should go too)
I was hoping to explore that a bit further to see where it leads to. But it will of course also
make sense for a TcProvider too. What do you think?
Compared to many other implementations of TcProvider this one has relatively few methods
that throw a NotImplementedException: createMGraph, deleteTripleCollection and here
it even makes sense to deleteTripleCollection . And it may even be possible to envisage it making
sense to create one in the longer term....
>
>>> So you're welcome to make suggestion on how it
>>> should be different,
>>
>> I have not really had time to study all your local TcProviders, nor
>> work out how a number can help anything distinguish between one TcProvider
>> and another. I have to go right now - my sister is calling...
>>
>> But here is a quick question: why not simply make the ProxyTcProvider a higher priority than the
>> pure local one?
> We wouldn't know when to try to dereference a graph and when not.
Any Resource that is not local, that can be dereferenced (http, https, ftp, ftps,...) (that is not on some blacklist) can be dereferenced.
Any resources that are local (localhost domain, or the name of the current machine
is running on) should be passed to the next TcProvider.
So my feeling here is that TcProviders should be arranged a bit like a Servlet Filter, each one does something, if it cannot do it, it passes it on to the next one in the stack. Then one can build stacks of Providers. (I have only looked at 3 or four implementations of TcProvider).
(Perhaps a simple stack is too simple...)
> I propose to name our default graphs with localinstance-uris but it
> shall still be possible to store a triplecollection with any name in
> TcManager (again doing the least possible change to the behaviour of
> the public api). Thus we wouldn't know for a graph named with a
> dereferenceable uri if we should try to update it of if the local copy
> is authoritative (and trying to update would generate a circle).
Ok so what you want is in fact something you had not explained before.
You want remote graphs that should not be fetched, say foaf, or owl to
be at their namesepace in the TcManager. So the name of the foaf graph should
be
http://xmlns.com/foaf/0.1/ [ mhh foaf is a difficult one ]
the cert graph should be named
http://www.w3.org/ns/auth/cert#
the owl graph should be named
http://www.w3.org/2002/07/owl
Anyway, these should be looked at carefully, because we can get good feedback from the semweb community on how those graphs should be called.
Then all graphs that are fetched through the cache should be called
urn:x-localinstance:/cache/<remote-uri>
Because then you can have a simple fall through logic of TcManagers, where if it is not found in the first TcManager, the next WebProxy TcManager can fetch it.
Is that it?
>>
>>> but without other proposal and without you
>>> withdrawing the -1 I have to change it to
>>> name.getUnicodeString+".cache" which was the last (silently) accepted
>>> name. I think we both agree that localinstance is better than the
>>> .cache proposal, so I urge you to revoke your vote.
> Above you confirmed that you agree that
> urn:x-localinstance:/cache/<remote-uri> is better than
> <remote-uri>.cache so I don't understand why you're still vetoing this
> change.
This is a very important discussion I think. We are progressing.
Henry
>
> Reto
>
>
>>>
>>> Cheers,
>>> Reto
>>>
>>> On Sun, May 15, 2011 at 12:17 AM, Henry Story <he...@bblfish.net> wrote:
>>>> I would like you first to read through the extensive mail I wrote, which took
>>>> me some time to write, and think things through.
>>>>
>>>>
>>>> Henry
>>>>
>>>> On 14 May 2011, at 22:37, Reto Bachmann-Gmuer wrote:
>>>>
>>>>> On Sat, May 14, 2011 at 7:54 PM, Henry Story <he...@bblfish.net> wrote:
>>>>>> Btw, I suppose I should say that I am not massively against the suggestion
>>>>>> you started this thread with. It is more than I am trying to explore this
>>>>>> more carefully, because it is an important discussion that deserves careful
>>>>>> thought.
>>>>> The careful procedure is to have tiny little issues which when
>>>>> resolved bring a tiny but undisputed improvement. Now with your
>>>>> resolution of CLEREZZA-463 I'm having massive problems and even if you
>>>>> think the status quo ante was fundamentally wrong I believe the
>>>>> graph-renaming you did makes things worse.
>>>>>
>>>>> I know that CLEREZZA-463 contains many real improvement. But it also
>>>>> introduce problems. And not just what you might consider a
>>>>> philosophical problem that names denote extensionally different things
>>>>> but also very practical ones.
>>>>>
>>>>> One major problem is the permission. We introduces
>>>>> WebIdBasedPermissionProvider and one implementation
>>>>> (UserGraphAcessPermissionProvider) used to provide readwrite access to
>>>>> the profile graph. Now this no longer works because you changed the
>>>>> names of graphs. Because of this and not because of a fundamentally
>>>>> broken architecture before your patch applications that used to work.
>>>>>
>>>>> Your -1 was against urn:x-localinstance:/cache/<remote-uri>
>>>>>
>>>>> The status quo ante was
>>>>>
>>>>> cache graph: <web-profile-uri>.cache
>>>>> profie-graph: <web-profile-uri>
>>>>>
>>>>> with the resolution of CLEREZZA-463 we have
>>>>>
>>>>> cache graph <web-profile-uri>
>>>>> profile graphs for local users: <web-profile-uri>
>>>>> profile graphs for remote users: <default-base-uri>/<web-profile-uri>
>>>>>
>>>>> you did change some names, probably just because of inconsistent
>>>>> changes things broke (UserGraphAcessPermissionProvider seems pointless
>>>>> right now). I don't want to
>>>>>
>>>>> and such that because of the renaming of graphs the
>>>>> UserGraphAcessPermissionProvider
>>>>>
>>>>> - The user has no longer the right to write to its own graph
>>>>> - Because the user graphs that is now (with your resolution of
>>>>> CLEREZZA-463) named like
>>>>> <http://localhost:8080/user/https://farewellutopia.com/user/me/profile>
>>>>>
>>>>> In my opinion to changed a suboptimal solution against quite a mess,
>>>>> now you argue against my solution to tidy things up because you are
>>>>> afraid of having a mess in one year.
>>>>>
>>>>> So please either accept my proposal which started this thread as
>>>>> something that is better than the status quo (i.e. retract your -1 so
>>>>> I can finally go back coding) or make a concrete proposal on how to
>>>>> name the different entities I've been suggesting names for or else
>>>>> revert the changes for CLEREZZA-463 (so that applications that used to
>>>>> work work again and we can start a proper development with little
>>>>> issues and patches that represent undisputed improvements.
>>>>>
>>>>>
>>>>> ==== what I consider important and relevant to current development
>>>>> ends here ====
>>>>>
>>>>>>
>>>>>> On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
>>>>>>
>>>>>>> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>>>>>>>> Reto wrote:
>>>>>>>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>>>>>>>> that I'm stating rather than arguing.
>>>>>>>> :-)
>>>>>>>>> The argument: they are different thing, both intensionally (cache and
>>>>>>>>> source) as in many case extensionally (triples may differ).
>>>>>>>>
>>>>>>>> in that sense I agree.
>>>>>>>> But then the other point I made is also true, and that is that different
>>>>>>>> users may get different
>>>>>>>> graphs back for the same remote resource. In fact those users may be the
>>>>>>>> same user at different times. Since those are all different graphs by your
>>>>>>>> definition above one should also give them different names.
>>>>>>> We do not have support for this yet and I think its a feature
>>>>>>> increasing complexity massively.
>>>>>>
>>>>>> You are dealing with an architectural problem which cannot just be dealt
>>>>>> with in stages. You need to look at the problem as a whole, or you will
>>>>>> just end up with the problem we are having right now. It is better to get this
>>>>>> issue cleared up now, than have a mess of graph names in one year, when a lot of
>>>>>> applications depend on this.
>>>>> This kind of against agile mantras and it seems to contrast very
>>>>> strongly to what you just did: you changed the names and now want a
>>>>> scientific study to change them again to solve the problems your
>>>>> namechange introduced.
>>>>>
>>>>>>
>>>>>> In any case it's not increasing anything massively, it is the logical
>>>>>> continuation of your point above.
>>>>> If you propose a patch which changes names and deliver good arguments
>>>>> why the new names are massively better and support future usecases
>>>>> without any disadvantage for addressing the current usecases than I'm
>>>>> sure this gets accepted, what you did is mix-in this namechange in a
>>>>> whole bunch of patches.
>>>>>
>>>>>>
>>>>>> Your argument was:
>>>>>>
>>>>>> "they [the remote and the locally fetched graph] are different thing, both
>>>>>> intensionally (cache and source) as in many case extensionally (triples may differ)."
>>>>>>
>>>>>> And so it follows that graphs sent at different times may also differ
>>>>>> extensionally and should have different names too.
>>>>>
>>>>> No, we are talking about MGraphs here. I know transtemporal identity
>>>>> is a hard problem philosophically yet in practice we have quite strong
>>>>> intuition on what we consider to be the same thing over time. the
>>>>> google website remains the google website even if they change the
>>>>> design, same goes for the wikipedia page about google it remains the
>>>>> wikipedia site about google (with the same URI) even after it was
>>>>> changed, one never becomes the other.
>>>>>
>>>>>>
>>>>>> You can't have it both ways, argue on intentionality for different names and then
>>>>>> refuse to see that temporally different graphs would also then need different names.
>>>>> I was talking about intensionality. Two terms have a same intension
>>>>> only is in the same universe of evaluation and at the same point in
>>>>> time they have the same extension.
>>>>>
>>>>>>
>>>>>> ( Btw. there are good arguments that intentionally the local graph if it is a cache
>>>>>> does not differ from the remote one. In any case if you pursue this too far you will
>>>>>> find that you can never name any remote thing. )
>>>>>>
>>>>>>> I don't think that clerezza-490 need to be resolved urgently, but anyway we
>>>>>>> should proceed issue by issue, and the best resolution of an issue is a minimal
>>>>>>> resolution not one that tries to foresee and future issues.
>>>>>>
>>>>>> I tend to see logical consequences of an argument as being contained in the argument,
>>>>>> and not being future issues that can be looked at later as somehow being distinct.
>>>>> yes, but:
>>>>> 1. analysing till the very bottom inevitably leads to paralysis.
>>>>> 2. this inconsistent with your intuition based named change without discussion
>>>>> 3. We have problems needing a fix (only to be as good as before your
>>>>> patches) and you're not making a concrete proposal
>>>>>
>>>>>>
>>>>>> Clerezza-490 that deals with different ways the server can present itself to other
>>>>>> servers, is not of course something that needs to be implemented immediately. But it
>>>>>> would be good that the naming solution we come up with can be extended to that case
>>>>>> and to the temporal case.
>>>>>>
>>>>>> So I am invoking Clerezza-490 as something to help test the naming ideas being put
>>>>>> forward here. This is a logical test if you will.
>>>>> see above
>>>>>
>>>>>>
>>>>>>>> So local graph naming schemes should take that into account, which is why I
>>>>>>>> suggest that we have an API that can allow for extensibility here.
>>>>>>> We have currently things and we are naming them badly.
>>>>>>>
>>>>>>> Prior to you r webproxy we had:
>>>>>>> <webid-profile-url>.cache as name for the cache of the webprofile
>>>>>>> and
>>>>>>> <webid-profile-url> as uri for triples the user generated locally,
>>>>>>> this can be seen as extensions to the remote profile with information
>>>>>>> (like preferred language) that happen not to be in the remote profile
>>>>>>>
>>>>>>> which was consistent with local users who only had
>>>>>>> <webid-profile-url> for the triples they control which include both
>>>>>>> the regular profile as well
>>>>>>
>>>>>> yes, and both of those were not good solutions.
>>>>>> The .cache solution is bound to create a problem if someone remotely has
>>>>>> a URI named http://some.example/resource.cache
>>>>>>
>>>>>> It is bound to lead to nasty name clashes, with the same URI naming two different things.
>>>>> right, I'm admitting it wasn't ideal - but I preffere the seldom
>>>>> clashes to the ambiguity by design.
>>>>>
>>>>>>
>>>>>> Remote URIs are named by remote resources, so it makes more sense to use the URI of the
>>>>>> remote resource to name the graph of the remote resource. The remote resource was named
>>>>>> by the owner of the resource. We should respect that.
>>>>> <sarcasm>so we nshould not do caching, as the uri prefix http implies
>>>>> a preferred method for retrieving the resource which is definitively
>>>>> different than getting it out of a local tdb store</sarcasm>
>>>>>
>>>>>>
>>>>>> If there are local additions to a remote graph, they should be given a local
>>>>>> URI. There is nothing simpler than this solution it seems to me.
>>>>>>
>>>>>>>
>>>>>>> Now <webid-profile-url> is the cache,
>>>>>>
>>>>>> You can look at it that way, or you can think of it as the name of the remote
>>>>>> graph, with the contents being the cache of the remote graph.
>>>>>>
>>>>>> If you were to make the local graph available publicly, it would then of
>>>>>> course need to have a local url tied into your namespace. Perhaps this is a good
>>>>>> way to think of the distinction.
>>>>>
>>>>> I'm noty saying your proposal is absurd, but you introduced in a way
>>>>> that breaks things an without discussion. now that I want to clean the
>>>>> mess you start writing socio-philosophical essays
>>>>>
>>>>>>
>>>>>>
>>>>>>> not sure where additional
>>>>>>> triples added locally get stored, i.e. where triples added to
>>>>>>> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
>>>>>>
>>>>>>
>>>>>> They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
>>>>>>
>>>>>> So currently as an initial proposal I put them in
>>>>> as a proposal ok, but you changed something that was working without
>>>>> dissusing the consequences this e.g. for permissions.
>>>>>
>>>>> <snip/>
>>>>>> Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
>>>>>>
>>>>>> A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
>>>>>>
>>>>>> By giving apps access to name spaces you can also make sure that there won't be any clashes.
>>>>> there is nothing that prevent application from making there own graphs
>>>>> for user information.
>>>>>
>>>>>>
>>>>>> now, that could be a reason for having URIs like
>>>>>>
>>>>>> mvn:/dev.net/application1/?user=webid...
>>>>>>
>>>>>> But then you see that applications on different servers will have name clashes too if they
>>>>>> ever merge their databases.
>>>>>>
>>>>>> The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
>>>>>>
>>>>>>> I'm not saying the old naming was perfect but it worked in a somehow
>>>>>>> consistent fashion for local and remote users.
>>>>>>
>>>>>> It was very confusing to me at least, as I point out in CLEREZZA-489.
>>>>>>
>>>>>> And it furthermore is inconsistent with your point above that remote graphs are
>>>>>> intentionally different from the local version.
>>>>>>
>>>>>>> Now my application taht used this feature is now longer working.
>>>>>>
>>>>>> Well that is the problem of having an initial system that is broken.
>>>>>> It will be easy to fix this, and we should fix it well, not do a half job of it,
>>>>>> because this is a distributed naming problem.
>>>>> I'm tired. I've nothing against a concrete counter proposal against
>>>>> the one that started the tread, e.g. saying: "we must give every
>>>>> instance a unique-id and this should be part of the
>>>>> x-localinstance-uri"
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> in Clerezza-489 I wrote that one could describe each graph like this in a
>>>>>>>> special Cache graph perhaps.
>>>>>>>> :g202323 a :Graph;
>>>>>>>> = { ... };
>>>>>>>> :fetchedFrom <https://remote.com/>;
>>>>>>>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>>>>>>>> :representation <file:/tmp/repr/202323>;
>>>>>>>> :httpMeta [ etag "sdfsdfsddfs";
>>>>>>>> validTo "2012...."^^xsd:dateTime;
>>>>>>>> ... redirected info?
>>>>>>>> ] .
>>>>>>>>
>>>>>>>> :g202324 a :Graph;
>>>>>>>> = { ... };
>>>>>>>> :fetchedFrom <https://remote.com/>;
>>>>>>>> :fetchedBy <http://farewellutopia.com/reto#me>;
>>>>>>>> :representation <file:/tmp/repr/202324>;
>>>>>>>> :httpMeta [ etag "ddfsdfsddfd";
>>>>>>>> validTo "2012...."^^xsd:dateTime;
>>>>>>>> ... redirected info?
>>>>>>>> ] .
>>>>>>>
>>>>>>> If we had barketing in RDF and our tooling would support it the the
>>>>>>> above might be somehow topical, answer to the question "how to name
>>>>>>> this?" "don't name it".
>>>>>>
>>>>>> The above is just a way of writing the contents of the graph and the metadata
>>>>>> in the same file. That is what the
>>>>>>
>>>>>> :g202323 = { ... }
>>>>>>
>>>>>> is about. You don't need any special tools for that. If you use Jena to get the graph
>>>>>> named above you would get the content of the brackets. The point is that the content
>>>>>> from
>>>>> Also in jena the graphs have a name, very profane sequence of
>>>>> characters this discussion was about. So in clerezza of in jena in the
>>>>> metadata graph you have a name instead of {...} and for this name you
>>>>> will get {...} from the named graph store.
>>>>>
>>>>>>
>>>>>> :fetchedFrom ..
>>>>>> :fetchedBy ...
>>>>>>
>>>>>> is not in the g202323 graph, but in a graph metadata graph.
>>>>> obviously
>>>>>>
>>>>>>> Please lets proceed issue by issue and make
>>>>>>> sure every brick we place is really solid and separate this from
>>>>>>> visionary long term stuff.
>>>>>>
>>>>>> Ok, I hope you see that I introduced nothing new there. It's just an
>>>>>> n3 notation that makes it easy to write things out in an e-mail.
>>>>> an n3 notaions that omits exactly what this discussion is about,
>>>>> namely my nameing proposal and your -1 gainst it.
>>>>>
>>>>>>
>>>>>> So please consider that point again in that light.
>>>>>>
>>>>>>>>
>>>>>>>> Then this API could use information from this graph to and information from
>>>>>>>> the user's request
>>>>>>>> to find the correct local graph he wants.
>>>>>>> Still the local graph would have a name, probably - but as I said its
>>>>>>> irrelevant. Lets deal with the issues at hand, you changed the names
>>>>>>> of graph (which I agree didn't have the best possible names) with
>>>>>>> names that I think are worse, lets find something we can agree upon.
>>>>>>> (otherwise, please roll back to the version with the orginal names
>>>>>>> till we find a consensus).
>>>>>>
>>>>>> Well I don't think rolling back would improve anything. I think clearly
>>>>>> this was an improvement. But I do think we can do better.
>>>>> It a mixture between improvements and deterioration. following the
>>>>> right process avoids the deterioations
>>>>>
>>>>>
>>>>>>
>>>>>> So my thinking is that to reach consensus we can do this with an API, without
>>>>>> deciding what precisely the names should be.
>>>>> Stop: I disagree with your new names and we have problems because of
>>>>> your name changes and now you dont want to decide about names?!
>>>>>
>>>>>> The best is just to lay out the
>>>>>> requirements:
>>>>>>
>>>>>> 1. mapping from a remote URI to the URI understood by the local triple store
>>>>>> and back. There should be no name clashes. It should be possible to easily extend
>>>>>> to have agent views and temporal views.
>>>>>>
>>>>>> 2. method for applications to take hold of legitimate namespaces in such a way that
>>>>>> a clash of names is not possible.
>>>>>
>>>>> If any proposal for changing names satisfies one of your criteria less
>>>>> than the staus before the poposal your applying the argument to the
>>>>> concrete proposal is welcome.
>>>>>
>>>>> Reto
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Henry
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Reto
>>>>>>>
>>>>>>>> Henry
>>>>>>>> PS. Having said that one then may just wonder why local graphs should ever
>>>>>>>> have anything other than
>>>>>>>> local URLs, since every time someone made a copy of a local graph it would
>>>>>>>> be different.
>>>>>>
>>>>>> Social Web Architect
>>>>>> http://bblfish.net/
>>>>>>
>>>>>>
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
On Sun, May 15, 2011 at 11:28 AM, Henry Story <he...@bblfish.net> wrote:
> And we did boil things down to the question of why we need
>
> urn:x-localinstance:/cache/<remote-uri>
>
> rather than just
>
> <remote-uri>
>
> We both agree that either is an improvement over <remote-uri>.cache
no, we just both agree that <remote-uri>.cache is ugly. But imho
<remote-uri> isn't practicable (at least as long as we want to keep
this in the rdf.*-bundle set and not have this be part of platform.*).
> Ok, so this issue is occurring because you are refactoring WebProxy to be a
> TcProvider, which it was not originally. One can of course see the pull to
> making it a TcProvider, though perhaps the delete methods are not so useful
> there.
Virtual TcProvider typically don't implement these. I think we shall
have good reasons to extends the publi api. With my suggestion we
extend it by just one class, one public member and one enumeration.
With you proposal - after i reduced visibility of some members - there
are still 2 new public classes with 6 new public members and one
enumeration. For the public APIs change and extensions we accept into
trunk we should be more conservative than just for implementation,
especially for a core component like this Proxy.
>> So you're welcome to make suggestion on how it
>> should be different,
>
> I have not really had time to study all your local TcProviders, nor
> work out how a number can help anything distinguish between one TcProvider
> and another. I have to go right now - my sister is calling...
>
> But here is a quick question: why not simply make the ProxyTcProvider a higher priority than the
> pure local one?
We wouldn't know when to try to dereference a graph and when not. I
propose to name our default graphs with localinstance-uris but it
shall still be possible to store a triplecollection with any name in
TcManager (again doing the least possible change to the behaviour of
the public api). Thus we wouldn't know for a graph named with a
dereferenceable uri if we should try to update it of if the local copy
is authoritative (and trying to update would generate a circle).
>
>> but without other proposal and without you
>> withdrawing the -1 I have to change it to
>> name.getUnicodeString+".cache" which was the last (silently) accepted
>> name. I think we both agree that localinstance is better than the
>> .cache proposal, so I urge you to revoke your vote.
Above you confirmed that you agree that
urn:x-localinstance:/cache/<remote-uri> is better than
<remote-uri>.cache so I don't understand why you're still vetoing this
change.
Reto
>>
>> Cheers,
>> Reto
>>
>> On Sun, May 15, 2011 at 12:17 AM, Henry Story <he...@bblfish.net> wrote:
>>> I would like you first to read through the extensive mail I wrote, which took
>>> me some time to write, and think things through.
>>>
>>>
>>> Henry
>>>
>>> On 14 May 2011, at 22:37, Reto Bachmann-Gmuer wrote:
>>>
>>>> On Sat, May 14, 2011 at 7:54 PM, Henry Story <he...@bblfish.net> wrote:
>>>>> Btw, I suppose I should say that I am not massively against the suggestion
>>>>> you started this thread with. It is more than I am trying to explore this
>>>>> more carefully, because it is an important discussion that deserves careful
>>>>> thought.
>>>> The careful procedure is to have tiny little issues which when
>>>> resolved bring a tiny but undisputed improvement. Now with your
>>>> resolution of CLEREZZA-463 I'm having massive problems and even if you
>>>> think the status quo ante was fundamentally wrong I believe the
>>>> graph-renaming you did makes things worse.
>>>>
>>>> I know that CLEREZZA-463 contains many real improvement. But it also
>>>> introduce problems. And not just what you might consider a
>>>> philosophical problem that names denote extensionally different things
>>>> but also very practical ones.
>>>>
>>>> One major problem is the permission. We introduces
>>>> WebIdBasedPermissionProvider and one implementation
>>>> (UserGraphAcessPermissionProvider) used to provide readwrite access to
>>>> the profile graph. Now this no longer works because you changed the
>>>> names of graphs. Because of this and not because of a fundamentally
>>>> broken architecture before your patch applications that used to work.
>>>>
>>>> Your -1 was against urn:x-localinstance:/cache/<remote-uri>
>>>>
>>>> The status quo ante was
>>>>
>>>> cache graph: <web-profile-uri>.cache
>>>> profie-graph: <web-profile-uri>
>>>>
>>>> with the resolution of CLEREZZA-463 we have
>>>>
>>>> cache graph <web-profile-uri>
>>>> profile graphs for local users: <web-profile-uri>
>>>> profile graphs for remote users: <default-base-uri>/<web-profile-uri>
>>>>
>>>> you did change some names, probably just because of inconsistent
>>>> changes things broke (UserGraphAcessPermissionProvider seems pointless
>>>> right now). I don't want to
>>>>
>>>> and such that because of the renaming of graphs the
>>>> UserGraphAcessPermissionProvider
>>>>
>>>> - The user has no longer the right to write to its own graph
>>>> - Because the user graphs that is now (with your resolution of
>>>> CLEREZZA-463) named like
>>>> <http://localhost:8080/user/https://farewellutopia.com/user/me/profile>
>>>>
>>>> In my opinion to changed a suboptimal solution against quite a mess,
>>>> now you argue against my solution to tidy things up because you are
>>>> afraid of having a mess in one year.
>>>>
>>>> So please either accept my proposal which started this thread as
>>>> something that is better than the status quo (i.e. retract your -1 so
>>>> I can finally go back coding) or make a concrete proposal on how to
>>>> name the different entities I've been suggesting names for or else
>>>> revert the changes for CLEREZZA-463 (so that applications that used to
>>>> work work again and we can start a proper development with little
>>>> issues and patches that represent undisputed improvements.
>>>>
>>>>
>>>> ==== what I consider important and relevant to current development
>>>> ends here ====
>>>>
>>>>>
>>>>> On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
>>>>>
>>>>>> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>>>>>>> Reto wrote:
>>>>>>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>>>>>>> that I'm stating rather than arguing.
>>>>>>> :-)
>>>>>>>> The argument: they are different thing, both intensionally (cache and
>>>>>>>> source) as in many case extensionally (triples may differ).
>>>>>>>
>>>>>>> in that sense I agree.
>>>>>>> But then the other point I made is also true, and that is that different
>>>>>>> users may get different
>>>>>>> graphs back for the same remote resource. In fact those users may be the
>>>>>>> same user at different times. Since those are all different graphs by your
>>>>>>> definition above one should also give them different names.
>>>>>> We do not have support for this yet and I think its a feature
>>>>>> increasing complexity massively.
>>>>>
>>>>> You are dealing with an architectural problem which cannot just be dealt
>>>>> with in stages. You need to look at the problem as a whole, or you will
>>>>> just end up with the problem we are having right now. It is better to get this
>>>>> issue cleared up now, than have a mess of graph names in one year, when a lot of
>>>>> applications depend on this.
>>>> This kind of against agile mantras and it seems to contrast very
>>>> strongly to what you just did: you changed the names and now want a
>>>> scientific study to change them again to solve the problems your
>>>> namechange introduced.
>>>>
>>>>>
>>>>> In any case it's not increasing anything massively, it is the logical
>>>>> continuation of your point above.
>>>> If you propose a patch which changes names and deliver good arguments
>>>> why the new names are massively better and support future usecases
>>>> without any disadvantage for addressing the current usecases than I'm
>>>> sure this gets accepted, what you did is mix-in this namechange in a
>>>> whole bunch of patches.
>>>>
>>>>>
>>>>> Your argument was:
>>>>>
>>>>> "they [the remote and the locally fetched graph] are different thing, both
>>>>> intensionally (cache and source) as in many case extensionally (triples may differ)."
>>>>>
>>>>> And so it follows that graphs sent at different times may also differ
>>>>> extensionally and should have different names too.
>>>>
>>>> No, we are talking about MGraphs here. I know transtemporal identity
>>>> is a hard problem philosophically yet in practice we have quite strong
>>>> intuition on what we consider to be the same thing over time. the
>>>> google website remains the google website even if they change the
>>>> design, same goes for the wikipedia page about google it remains the
>>>> wikipedia site about google (with the same URI) even after it was
>>>> changed, one never becomes the other.
>>>>
>>>>>
>>>>> You can't have it both ways, argue on intentionality for different names and then
>>>>> refuse to see that temporally different graphs would also then need different names.
>>>> I was talking about intensionality. Two terms have a same intension
>>>> only is in the same universe of evaluation and at the same point in
>>>> time they have the same extension.
>>>>
>>>>>
>>>>> ( Btw. there are good arguments that intentionally the local graph if it is a cache
>>>>> does not differ from the remote one. In any case if you pursue this too far you will
>>>>> find that you can never name any remote thing. )
>>>>>
>>>>>> I don't think that clerezza-490 need to be resolved urgently, but anyway we
>>>>>> should proceed issue by issue, and the best resolution of an issue is a minimal
>>>>>> resolution not one that tries to foresee and future issues.
>>>>>
>>>>> I tend to see logical consequences of an argument as being contained in the argument,
>>>>> and not being future issues that can be looked at later as somehow being distinct.
>>>> yes, but:
>>>> 1. analysing till the very bottom inevitably leads to paralysis.
>>>> 2. this inconsistent with your intuition based named change without discussion
>>>> 3. We have problems needing a fix (only to be as good as before your
>>>> patches) and you're not making a concrete proposal
>>>>
>>>>>
>>>>> Clerezza-490 that deals with different ways the server can present itself to other
>>>>> servers, is not of course something that needs to be implemented immediately. But it
>>>>> would be good that the naming solution we come up with can be extended to that case
>>>>> and to the temporal case.
>>>>>
>>>>> So I am invoking Clerezza-490 as something to help test the naming ideas being put
>>>>> forward here. This is a logical test if you will.
>>>> see above
>>>>
>>>>>
>>>>>>> So local graph naming schemes should take that into account, which is why I
>>>>>>> suggest that we have an API that can allow for extensibility here.
>>>>>> We have currently things and we are naming them badly.
>>>>>>
>>>>>> Prior to you r webproxy we had:
>>>>>> <webid-profile-url>.cache as name for the cache of the webprofile
>>>>>> and
>>>>>> <webid-profile-url> as uri for triples the user generated locally,
>>>>>> this can be seen as extensions to the remote profile with information
>>>>>> (like preferred language) that happen not to be in the remote profile
>>>>>>
>>>>>> which was consistent with local users who only had
>>>>>> <webid-profile-url> for the triples they control which include both
>>>>>> the regular profile as well
>>>>>
>>>>> yes, and both of those were not good solutions.
>>>>> The .cache solution is bound to create a problem if someone remotely has
>>>>> a URI named http://some.example/resource.cache
>>>>>
>>>>> It is bound to lead to nasty name clashes, with the same URI naming two different things.
>>>> right, I'm admitting it wasn't ideal - but I preffere the seldom
>>>> clashes to the ambiguity by design.
>>>>
>>>>>
>>>>> Remote URIs are named by remote resources, so it makes more sense to use the URI of the
>>>>> remote resource to name the graph of the remote resource. The remote resource was named
>>>>> by the owner of the resource. We should respect that.
>>>> <sarcasm>so we nshould not do caching, as the uri prefix http implies
>>>> a preferred method for retrieving the resource which is definitively
>>>> different than getting it out of a local tdb store</sarcasm>
>>>>
>>>>>
>>>>> If there are local additions to a remote graph, they should be given a local
>>>>> URI. There is nothing simpler than this solution it seems to me.
>>>>>
>>>>>>
>>>>>> Now <webid-profile-url> is the cache,
>>>>>
>>>>> You can look at it that way, or you can think of it as the name of the remote
>>>>> graph, with the contents being the cache of the remote graph.
>>>>>
>>>>> If you were to make the local graph available publicly, it would then of
>>>>> course need to have a local url tied into your namespace. Perhaps this is a good
>>>>> way to think of the distinction.
>>>>
>>>> I'm noty saying your proposal is absurd, but you introduced in a way
>>>> that breaks things an without discussion. now that I want to clean the
>>>> mess you start writing socio-philosophical essays
>>>>
>>>>>
>>>>>
>>>>>> not sure where additional
>>>>>> triples added locally get stored, i.e. where triples added to
>>>>>> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
>>>>>
>>>>>
>>>>> They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
>>>>>
>>>>> So currently as an initial proposal I put them in
>>>> as a proposal ok, but you changed something that was working without
>>>> dissusing the consequences this e.g. for permissions.
>>>>
>>>> <snip/>
>>>>> Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
>>>>>
>>>>> A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
>>>>>
>>>>> By giving apps access to name spaces you can also make sure that there won't be any clashes.
>>>> there is nothing that prevent application from making there own graphs
>>>> for user information.
>>>>
>>>>>
>>>>> now, that could be a reason for having URIs like
>>>>>
>>>>> mvn:/dev.net/application1/?user=webid...
>>>>>
>>>>> But then you see that applications on different servers will have name clashes too if they
>>>>> ever merge their databases.
>>>>>
>>>>> The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
>>>>>
>>>>>> I'm not saying the old naming was perfect but it worked in a somehow
>>>>>> consistent fashion for local and remote users.
>>>>>
>>>>> It was very confusing to me at least, as I point out in CLEREZZA-489.
>>>>>
>>>>> And it furthermore is inconsistent with your point above that remote graphs are
>>>>> intentionally different from the local version.
>>>>>
>>>>>> Now my application taht used this feature is now longer working.
>>>>>
>>>>> Well that is the problem of having an initial system that is broken.
>>>>> It will be easy to fix this, and we should fix it well, not do a half job of it,
>>>>> because this is a distributed naming problem.
>>>> I'm tired. I've nothing against a concrete counter proposal against
>>>> the one that started the tread, e.g. saying: "we must give every
>>>> instance a unique-id and this should be part of the
>>>> x-localinstance-uri"
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>> in Clerezza-489 I wrote that one could describe each graph like this in a
>>>>>>> special Cache graph perhaps.
>>>>>>> :g202323 a :Graph;
>>>>>>> = { ... };
>>>>>>> :fetchedFrom <https://remote.com/>;
>>>>>>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>>>>>>> :representation <file:/tmp/repr/202323>;
>>>>>>> :httpMeta [ etag "sdfsdfsddfs";
>>>>>>> validTo "2012...."^^xsd:dateTime;
>>>>>>> ... redirected info?
>>>>>>> ] .
>>>>>>>
>>>>>>> :g202324 a :Graph;
>>>>>>> = { ... };
>>>>>>> :fetchedFrom <https://remote.com/>;
>>>>>>> :fetchedBy <http://farewellutopia.com/reto#me>;
>>>>>>> :representation <file:/tmp/repr/202324>;
>>>>>>> :httpMeta [ etag "ddfsdfsddfd";
>>>>>>> validTo "2012...."^^xsd:dateTime;
>>>>>>> ... redirected info?
>>>>>>> ] .
>>>>>>
>>>>>> If we had barketing in RDF and our tooling would support it the the
>>>>>> above might be somehow topical, answer to the question "how to name
>>>>>> this?" "don't name it".
>>>>>
>>>>> The above is just a way of writing the contents of the graph and the metadata
>>>>> in the same file. That is what the
>>>>>
>>>>> :g202323 = { ... }
>>>>>
>>>>> is about. You don't need any special tools for that. If you use Jena to get the graph
>>>>> named above you would get the content of the brackets. The point is that the content
>>>>> from
>>>> Also in jena the graphs have a name, very profane sequence of
>>>> characters this discussion was about. So in clerezza of in jena in the
>>>> metadata graph you have a name instead of {...} and for this name you
>>>> will get {...} from the named graph store.
>>>>
>>>>>
>>>>> :fetchedFrom ..
>>>>> :fetchedBy ...
>>>>>
>>>>> is not in the g202323 graph, but in a graph metadata graph.
>>>> obviously
>>>>>
>>>>>> Please lets proceed issue by issue and make
>>>>>> sure every brick we place is really solid and separate this from
>>>>>> visionary long term stuff.
>>>>>
>>>>> Ok, I hope you see that I introduced nothing new there. It's just an
>>>>> n3 notation that makes it easy to write things out in an e-mail.
>>>> an n3 notaions that omits exactly what this discussion is about,
>>>> namely my nameing proposal and your -1 gainst it.
>>>>
>>>>>
>>>>> So please consider that point again in that light.
>>>>>
>>>>>>>
>>>>>>> Then this API could use information from this graph to and information from
>>>>>>> the user's request
>>>>>>> to find the correct local graph he wants.
>>>>>> Still the local graph would have a name, probably - but as I said its
>>>>>> irrelevant. Lets deal with the issues at hand, you changed the names
>>>>>> of graph (which I agree didn't have the best possible names) with
>>>>>> names that I think are worse, lets find something we can agree upon.
>>>>>> (otherwise, please roll back to the version with the orginal names
>>>>>> till we find a consensus).
>>>>>
>>>>> Well I don't think rolling back would improve anything. I think clearly
>>>>> this was an improvement. But I do think we can do better.
>>>> It a mixture between improvements and deterioration. following the
>>>> right process avoids the deterioations
>>>>
>>>>
>>>>>
>>>>> So my thinking is that to reach consensus we can do this with an API, without
>>>>> deciding what precisely the names should be.
>>>> Stop: I disagree with your new names and we have problems because of
>>>> your name changes and now you dont want to decide about names?!
>>>>
>>>>> The best is just to lay out the
>>>>> requirements:
>>>>>
>>>>> 1. mapping from a remote URI to the URI understood by the local triple store
>>>>> and back. There should be no name clashes. It should be possible to easily extend
>>>>> to have agent views and temporal views.
>>>>>
>>>>> 2. method for applications to take hold of legitimate namespaces in such a way that
>>>>> a clash of names is not possible.
>>>>
>>>> If any proposal for changing names satisfies one of your criteria less
>>>> than the staus before the poposal your applying the argument to the
>>>> concrete proposal is welcome.
>>>>
>>>> Reto
>>>>
>>>>
>>>>>
>>>>>
>>>>> Henry
>>>>>
>>>>>
>>>>>>
>>>>>> Reto
>>>>>>
>>>>>>> Henry
>>>>>>> PS. Having said that one then may just wonder why local graphs should ever
>>>>>>> have anything other than
>>>>>>> local URLs, since every time someone made a copy of a local graph it would
>>>>>>> be different.
>>>>>
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>>
>>>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>
> Social Web Architect
> http://bblfish.net/
>
>
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 15 May 2011, at 03:41, Reto Bachmann-Gmuer wrote:
> I apologize for for having wasted (not just my) time in engaging in
> this argument in such a non-constructive way.
Well we did get cover a lot of important issues in using URIs, many of which
I this discussion has helped bring back to the fore of my mind.
And we did boil things down to the question of why we need
urn:x-localinstance:/cache/<remote-uri>
rather than just
<remote-uri>
We both agree that either is an improvement over <remote-uri>.cache
>
> Let's talk code. Please have a look at parent/rdf.storage.web I just committed.
>
> What this thread is about is implemented in line 158 in
> http://svn.apache.org/viewvc/incubator/clerezza/trunk/parent/rdf.storage.web/src/main/scala/WebProxy.scala?revision=1103264&view=markup
>
> i.e.: val cacheGraphName = new UriRef("urn:x-localinstance:/cache/" +
> name.getUnicodeString)
>
> The code wouldn't work with cacheGraphName = name because in this
> case, once created the cache would always be provided by a higher
> priority WeightedTcProvider so that the caching Provider (WebProxy)
> never gets considered again and thus cannot update when the cache copy
> is considered outdated.
Ok, so this issue is occurring because you are refactoring WebProxy to be a
TcProvider, which it was not originally. One can of course see the pull to
making it a TcProvider, though perhaps the delete methods are not so useful
there.
> So you're welcome to make suggestion on how it
> should be different,
I have not really had time to study all your local TcProviders, nor
work out how a number can help anything distinguish between one TcProvider
and another. I have to go right now - my sister is calling...
But here is a quick question: why not simply make the ProxyTcProvider a higher priority than the
pure local one?
> but without other proposal and without you
> withdrawing the -1 I have to change it to
> name.getUnicodeString+".cache" which was the last (silently) accepted
> name. I think we both agree that localinstance is better than the
> .cache proposal, so I urge you to revoke your vote.
>
> Cheers,
> Reto
>
> On Sun, May 15, 2011 at 12:17 AM, Henry Story <he...@bblfish.net> wrote:
>> I would like you first to read through the extensive mail I wrote, which took
>> me some time to write, and think things through.
>>
>>
>> Henry
>>
>> On 14 May 2011, at 22:37, Reto Bachmann-Gmuer wrote:
>>
>>> On Sat, May 14, 2011 at 7:54 PM, Henry Story <he...@bblfish.net> wrote:
>>>> Btw, I suppose I should say that I am not massively against the suggestion
>>>> you started this thread with. It is more than I am trying to explore this
>>>> more carefully, because it is an important discussion that deserves careful
>>>> thought.
>>> The careful procedure is to have tiny little issues which when
>>> resolved bring a tiny but undisputed improvement. Now with your
>>> resolution of CLEREZZA-463 I'm having massive problems and even if you
>>> think the status quo ante was fundamentally wrong I believe the
>>> graph-renaming you did makes things worse.
>>>
>>> I know that CLEREZZA-463 contains many real improvement. But it also
>>> introduce problems. And not just what you might consider a
>>> philosophical problem that names denote extensionally different things
>>> but also very practical ones.
>>>
>>> One major problem is the permission. We introduces
>>> WebIdBasedPermissionProvider and one implementation
>>> (UserGraphAcessPermissionProvider) used to provide readwrite access to
>>> the profile graph. Now this no longer works because you changed the
>>> names of graphs. Because of this and not because of a fundamentally
>>> broken architecture before your patch applications that used to work.
>>>
>>> Your -1 was against urn:x-localinstance:/cache/<remote-uri>
>>>
>>> The status quo ante was
>>>
>>> cache graph: <web-profile-uri>.cache
>>> profie-graph: <web-profile-uri>
>>>
>>> with the resolution of CLEREZZA-463 we have
>>>
>>> cache graph <web-profile-uri>
>>> profile graphs for local users: <web-profile-uri>
>>> profile graphs for remote users: <default-base-uri>/<web-profile-uri>
>>>
>>> you did change some names, probably just because of inconsistent
>>> changes things broke (UserGraphAcessPermissionProvider seems pointless
>>> right now). I don't want to
>>>
>>> and such that because of the renaming of graphs the
>>> UserGraphAcessPermissionProvider
>>>
>>> - The user has no longer the right to write to its own graph
>>> - Because the user graphs that is now (with your resolution of
>>> CLEREZZA-463) named like
>>> <http://localhost:8080/user/https://farewellutopia.com/user/me/profile>
>>>
>>> In my opinion to changed a suboptimal solution against quite a mess,
>>> now you argue against my solution to tidy things up because you are
>>> afraid of having a mess in one year.
>>>
>>> So please either accept my proposal which started this thread as
>>> something that is better than the status quo (i.e. retract your -1 so
>>> I can finally go back coding) or make a concrete proposal on how to
>>> name the different entities I've been suggesting names for or else
>>> revert the changes for CLEREZZA-463 (so that applications that used to
>>> work work again and we can start a proper development with little
>>> issues and patches that represent undisputed improvements.
>>>
>>>
>>> ==== what I consider important and relevant to current development
>>> ends here ====
>>>
>>>>
>>>> On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
>>>>
>>>>> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>>>>>> Reto wrote:
>>>>>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>>>>>> that I'm stating rather than arguing.
>>>>>> :-)
>>>>>>> The argument: they are different thing, both intensionally (cache and
>>>>>>> source) as in many case extensionally (triples may differ).
>>>>>>
>>>>>> in that sense I agree.
>>>>>> But then the other point I made is also true, and that is that different
>>>>>> users may get different
>>>>>> graphs back for the same remote resource. In fact those users may be the
>>>>>> same user at different times. Since those are all different graphs by your
>>>>>> definition above one should also give them different names.
>>>>> We do not have support for this yet and I think its a feature
>>>>> increasing complexity massively.
>>>>
>>>> You are dealing with an architectural problem which cannot just be dealt
>>>> with in stages. You need to look at the problem as a whole, or you will
>>>> just end up with the problem we are having right now. It is better to get this
>>>> issue cleared up now, than have a mess of graph names in one year, when a lot of
>>>> applications depend on this.
>>> This kind of against agile mantras and it seems to contrast very
>>> strongly to what you just did: you changed the names and now want a
>>> scientific study to change them again to solve the problems your
>>> namechange introduced.
>>>
>>>>
>>>> In any case it's not increasing anything massively, it is the logical
>>>> continuation of your point above.
>>> If you propose a patch which changes names and deliver good arguments
>>> why the new names are massively better and support future usecases
>>> without any disadvantage for addressing the current usecases than I'm
>>> sure this gets accepted, what you did is mix-in this namechange in a
>>> whole bunch of patches.
>>>
>>>>
>>>> Your argument was:
>>>>
>>>> "they [the remote and the locally fetched graph] are different thing, both
>>>> intensionally (cache and source) as in many case extensionally (triples may differ)."
>>>>
>>>> And so it follows that graphs sent at different times may also differ
>>>> extensionally and should have different names too.
>>>
>>> No, we are talking about MGraphs here. I know transtemporal identity
>>> is a hard problem philosophically yet in practice we have quite strong
>>> intuition on what we consider to be the same thing over time. the
>>> google website remains the google website even if they change the
>>> design, same goes for the wikipedia page about google it remains the
>>> wikipedia site about google (with the same URI) even after it was
>>> changed, one never becomes the other.
>>>
>>>>
>>>> You can't have it both ways, argue on intentionality for different names and then
>>>> refuse to see that temporally different graphs would also then need different names.
>>> I was talking about intensionality. Two terms have a same intension
>>> only is in the same universe of evaluation and at the same point in
>>> time they have the same extension.
>>>
>>>>
>>>> ( Btw. there are good arguments that intentionally the local graph if it is a cache
>>>> does not differ from the remote one. In any case if you pursue this too far you will
>>>> find that you can never name any remote thing. )
>>>>
>>>>> I don't think that clerezza-490 need to be resolved urgently, but anyway we
>>>>> should proceed issue by issue, and the best resolution of an issue is a minimal
>>>>> resolution not one that tries to foresee and future issues.
>>>>
>>>> I tend to see logical consequences of an argument as being contained in the argument,
>>>> and not being future issues that can be looked at later as somehow being distinct.
>>> yes, but:
>>> 1. analysing till the very bottom inevitably leads to paralysis.
>>> 2. this inconsistent with your intuition based named change without discussion
>>> 3. We have problems needing a fix (only to be as good as before your
>>> patches) and you're not making a concrete proposal
>>>
>>>>
>>>> Clerezza-490 that deals with different ways the server can present itself to other
>>>> servers, is not of course something that needs to be implemented immediately. But it
>>>> would be good that the naming solution we come up with can be extended to that case
>>>> and to the temporal case.
>>>>
>>>> So I am invoking Clerezza-490 as something to help test the naming ideas being put
>>>> forward here. This is a logical test if you will.
>>> see above
>>>
>>>>
>>>>>> So local graph naming schemes should take that into account, which is why I
>>>>>> suggest that we have an API that can allow for extensibility here.
>>>>> We have currently things and we are naming them badly.
>>>>>
>>>>> Prior to you r webproxy we had:
>>>>> <webid-profile-url>.cache as name for the cache of the webprofile
>>>>> and
>>>>> <webid-profile-url> as uri for triples the user generated locally,
>>>>> this can be seen as extensions to the remote profile with information
>>>>> (like preferred language) that happen not to be in the remote profile
>>>>>
>>>>> which was consistent with local users who only had
>>>>> <webid-profile-url> for the triples they control which include both
>>>>> the regular profile as well
>>>>
>>>> yes, and both of those were not good solutions.
>>>> The .cache solution is bound to create a problem if someone remotely has
>>>> a URI named http://some.example/resource.cache
>>>>
>>>> It is bound to lead to nasty name clashes, with the same URI naming two different things.
>>> right, I'm admitting it wasn't ideal - but I preffere the seldom
>>> clashes to the ambiguity by design.
>>>
>>>>
>>>> Remote URIs are named by remote resources, so it makes more sense to use the URI of the
>>>> remote resource to name the graph of the remote resource. The remote resource was named
>>>> by the owner of the resource. We should respect that.
>>> <sarcasm>so we nshould not do caching, as the uri prefix http implies
>>> a preferred method for retrieving the resource which is definitively
>>> different than getting it out of a local tdb store</sarcasm>
>>>
>>>>
>>>> If there are local additions to a remote graph, they should be given a local
>>>> URI. There is nothing simpler than this solution it seems to me.
>>>>
>>>>>
>>>>> Now <webid-profile-url> is the cache,
>>>>
>>>> You can look at it that way, or you can think of it as the name of the remote
>>>> graph, with the contents being the cache of the remote graph.
>>>>
>>>> If you were to make the local graph available publicly, it would then of
>>>> course need to have a local url tied into your namespace. Perhaps this is a good
>>>> way to think of the distinction.
>>>
>>> I'm noty saying your proposal is absurd, but you introduced in a way
>>> that breaks things an without discussion. now that I want to clean the
>>> mess you start writing socio-philosophical essays
>>>
>>>>
>>>>
>>>>> not sure where additional
>>>>> triples added locally get stored, i.e. where triples added to
>>>>> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
>>>>
>>>>
>>>> They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
>>>>
>>>> So currently as an initial proposal I put them in
>>> as a proposal ok, but you changed something that was working without
>>> dissusing the consequences this e.g. for permissions.
>>>
>>> <snip/>
>>>> Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
>>>>
>>>> A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
>>>>
>>>> By giving apps access to name spaces you can also make sure that there won't be any clashes.
>>> there is nothing that prevent application from making there own graphs
>>> for user information.
>>>
>>>>
>>>> now, that could be a reason for having URIs like
>>>>
>>>> mvn:/dev.net/application1/?user=webid...
>>>>
>>>> But then you see that applications on different servers will have name clashes too if they
>>>> ever merge their databases.
>>>>
>>>> The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
>>>>
>>>>> I'm not saying the old naming was perfect but it worked in a somehow
>>>>> consistent fashion for local and remote users.
>>>>
>>>> It was very confusing to me at least, as I point out in CLEREZZA-489.
>>>>
>>>> And it furthermore is inconsistent with your point above that remote graphs are
>>>> intentionally different from the local version.
>>>>
>>>>> Now my application taht used this feature is now longer working.
>>>>
>>>> Well that is the problem of having an initial system that is broken.
>>>> It will be easy to fix this, and we should fix it well, not do a half job of it,
>>>> because this is a distributed naming problem.
>>> I'm tired. I've nothing against a concrete counter proposal against
>>> the one that started the tread, e.g. saying: "we must give every
>>> instance a unique-id and this should be part of the
>>> x-localinstance-uri"
>>>
>>>
>>>>
>>>>>
>>>>>> in Clerezza-489 I wrote that one could describe each graph like this in a
>>>>>> special Cache graph perhaps.
>>>>>> :g202323 a :Graph;
>>>>>> = { ... };
>>>>>> :fetchedFrom <https://remote.com/>;
>>>>>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>>>>>> :representation <file:/tmp/repr/202323>;
>>>>>> :httpMeta [ etag "sdfsdfsddfs";
>>>>>> validTo "2012...."^^xsd:dateTime;
>>>>>> ... redirected info?
>>>>>> ] .
>>>>>>
>>>>>> :g202324 a :Graph;
>>>>>> = { ... };
>>>>>> :fetchedFrom <https://remote.com/>;
>>>>>> :fetchedBy <http://farewellutopia.com/reto#me>;
>>>>>> :representation <file:/tmp/repr/202324>;
>>>>>> :httpMeta [ etag "ddfsdfsddfd";
>>>>>> validTo "2012...."^^xsd:dateTime;
>>>>>> ... redirected info?
>>>>>> ] .
>>>>>
>>>>> If we had barketing in RDF and our tooling would support it the the
>>>>> above might be somehow topical, answer to the question "how to name
>>>>> this?" "don't name it".
>>>>
>>>> The above is just a way of writing the contents of the graph and the metadata
>>>> in the same file. That is what the
>>>>
>>>> :g202323 = { ... }
>>>>
>>>> is about. You don't need any special tools for that. If you use Jena to get the graph
>>>> named above you would get the content of the brackets. The point is that the content
>>>> from
>>> Also in jena the graphs have a name, very profane sequence of
>>> characters this discussion was about. So in clerezza of in jena in the
>>> metadata graph you have a name instead of {...} and for this name you
>>> will get {...} from the named graph store.
>>>
>>>>
>>>> :fetchedFrom ..
>>>> :fetchedBy ...
>>>>
>>>> is not in the g202323 graph, but in a graph metadata graph.
>>> obviously
>>>>
>>>>> Please lets proceed issue by issue and make
>>>>> sure every brick we place is really solid and separate this from
>>>>> visionary long term stuff.
>>>>
>>>> Ok, I hope you see that I introduced nothing new there. It's just an
>>>> n3 notation that makes it easy to write things out in an e-mail.
>>> an n3 notaions that omits exactly what this discussion is about,
>>> namely my nameing proposal and your -1 gainst it.
>>>
>>>>
>>>> So please consider that point again in that light.
>>>>
>>>>>>
>>>>>> Then this API could use information from this graph to and information from
>>>>>> the user's request
>>>>>> to find the correct local graph he wants.
>>>>> Still the local graph would have a name, probably - but as I said its
>>>>> irrelevant. Lets deal with the issues at hand, you changed the names
>>>>> of graph (which I agree didn't have the best possible names) with
>>>>> names that I think are worse, lets find something we can agree upon.
>>>>> (otherwise, please roll back to the version with the orginal names
>>>>> till we find a consensus).
>>>>
>>>> Well I don't think rolling back would improve anything. I think clearly
>>>> this was an improvement. But I do think we can do better.
>>> It a mixture between improvements and deterioration. following the
>>> right process avoids the deterioations
>>>
>>>
>>>>
>>>> So my thinking is that to reach consensus we can do this with an API, without
>>>> deciding what precisely the names should be.
>>> Stop: I disagree with your new names and we have problems because of
>>> your name changes and now you dont want to decide about names?!
>>>
>>>> The best is just to lay out the
>>>> requirements:
>>>>
>>>> 1. mapping from a remote URI to the URI understood by the local triple store
>>>> and back. There should be no name clashes. It should be possible to easily extend
>>>> to have agent views and temporal views.
>>>>
>>>> 2. method for applications to take hold of legitimate namespaces in such a way that
>>>> a clash of names is not possible.
>>>
>>> If any proposal for changing names satisfies one of your criteria less
>>> than the staus before the poposal your applying the argument to the
>>> concrete proposal is welcome.
>>>
>>> Reto
>>>
>>>
>>>>
>>>>
>>>> Henry
>>>>
>>>>
>>>>>
>>>>> Reto
>>>>>
>>>>>> Henry
>>>>>> PS. Having said that one then may just wonder why local graphs should ever
>>>>>> have anything other than
>>>>>> local URLs, since every time someone made a copy of a local graph it would
>>>>>> be different.
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
I apologize for for having wasted (not just my) time in engaging in
this argument in such a non-constructive way.
Let's talk code. Please have a look at parent/rdf.storage.web I just committed.
What this thread is about is implemented in line 158 in
http://svn.apache.org/viewvc/incubator/clerezza/trunk/parent/rdf.storage.web/src/main/scala/WebProxy.scala?revision=1103264&view=markup
i.e.: val cacheGraphName = new UriRef("urn:x-localinstance:/cache/" +
name.getUnicodeString)
The code wouldn't work with cacheGraphName = name because in this
case, once created the cache would always be provided by a higher
priority WeightedTcProvider so that the caching Provider (WebProxy)
never gets considered again and thus cannot update when the cache copy
is considered outdated. So you're welcome to make suggestion on how it
should be different, but without other proposal and without you
withdrawing the -1 I have to change it to
name.getUnicodeString+".cache" which was the last (silently) accepted
name. I think we both agree that localinstance is better than the
.cache proposal, so I urge you to revoke your vote.
Cheers,
Reto
On Sun, May 15, 2011 at 12:17 AM, Henry Story <he...@bblfish.net> wrote:
> I would like you first to read through the extensive mail I wrote, which took
> me some time to write, and think things through.
>
>
> Henry
>
> On 14 May 2011, at 22:37, Reto Bachmann-Gmuer wrote:
>
>> On Sat, May 14, 2011 at 7:54 PM, Henry Story <he...@bblfish.net> wrote:
>>> Btw, I suppose I should say that I am not massively against the suggestion
>>> you started this thread with. It is more than I am trying to explore this
>>> more carefully, because it is an important discussion that deserves careful
>>> thought.
>> The careful procedure is to have tiny little issues which when
>> resolved bring a tiny but undisputed improvement. Now with your
>> resolution of CLEREZZA-463 I'm having massive problems and even if you
>> think the status quo ante was fundamentally wrong I believe the
>> graph-renaming you did makes things worse.
>>
>> I know that CLEREZZA-463 contains many real improvement. But it also
>> introduce problems. And not just what you might consider a
>> philosophical problem that names denote extensionally different things
>> but also very practical ones.
>>
>> One major problem is the permission. We introduces
>> WebIdBasedPermissionProvider and one implementation
>> (UserGraphAcessPermissionProvider) used to provide readwrite access to
>> the profile graph. Now this no longer works because you changed the
>> names of graphs. Because of this and not because of a fundamentally
>> broken architecture before your patch applications that used to work.
>>
>> Your -1 was against urn:x-localinstance:/cache/<remote-uri>
>>
>> The status quo ante was
>>
>> cache graph: <web-profile-uri>.cache
>> profie-graph: <web-profile-uri>
>>
>> with the resolution of CLEREZZA-463 we have
>>
>> cache graph <web-profile-uri>
>> profile graphs for local users: <web-profile-uri>
>> profile graphs for remote users: <default-base-uri>/<web-profile-uri>
>>
>> you did change some names, probably just because of inconsistent
>> changes things broke (UserGraphAcessPermissionProvider seems pointless
>> right now). I don't want to
>>
>> and such that because of the renaming of graphs the
>> UserGraphAcessPermissionProvider
>>
>> - The user has no longer the right to write to its own graph
>> - Because the user graphs that is now (with your resolution of
>> CLEREZZA-463) named like
>> <http://localhost:8080/user/https://farewellutopia.com/user/me/profile>
>>
>> In my opinion to changed a suboptimal solution against quite a mess,
>> now you argue against my solution to tidy things up because you are
>> afraid of having a mess in one year.
>>
>> So please either accept my proposal which started this thread as
>> something that is better than the status quo (i.e. retract your -1 so
>> I can finally go back coding) or make a concrete proposal on how to
>> name the different entities I've been suggesting names for or else
>> revert the changes for CLEREZZA-463 (so that applications that used to
>> work work again and we can start a proper development with little
>> issues and patches that represent undisputed improvements.
>>
>>
>> ==== what I consider important and relevant to current development
>> ends here ====
>>
>>>
>>> On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
>>>
>>>> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>>>>> Reto wrote:
>>>>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>>>>> that I'm stating rather than arguing.
>>>>> :-)
>>>>>> The argument: they are different thing, both intensionally (cache and
>>>>>> source) as in many case extensionally (triples may differ).
>>>>>
>>>>> in that sense I agree.
>>>>> But then the other point I made is also true, and that is that different
>>>>> users may get different
>>>>> graphs back for the same remote resource. In fact those users may be the
>>>>> same user at different times. Since those are all different graphs by your
>>>>> definition above one should also give them different names.
>>>> We do not have support for this yet and I think its a feature
>>>> increasing complexity massively.
>>>
>>> You are dealing with an architectural problem which cannot just be dealt
>>> with in stages. You need to look at the problem as a whole, or you will
>>> just end up with the problem we are having right now. It is better to get this
>>> issue cleared up now, than have a mess of graph names in one year, when a lot of
>>> applications depend on this.
>> This kind of against agile mantras and it seems to contrast very
>> strongly to what you just did: you changed the names and now want a
>> scientific study to change them again to solve the problems your
>> namechange introduced.
>>
>>>
>>> In any case it's not increasing anything massively, it is the logical
>>> continuation of your point above.
>> If you propose a patch which changes names and deliver good arguments
>> why the new names are massively better and support future usecases
>> without any disadvantage for addressing the current usecases than I'm
>> sure this gets accepted, what you did is mix-in this namechange in a
>> whole bunch of patches.
>>
>>>
>>> Your argument was:
>>>
>>> "they [the remote and the locally fetched graph] are different thing, both
>>> intensionally (cache and source) as in many case extensionally (triples may differ)."
>>>
>>> And so it follows that graphs sent at different times may also differ
>>> extensionally and should have different names too.
>>
>> No, we are talking about MGraphs here. I know transtemporal identity
>> is a hard problem philosophically yet in practice we have quite strong
>> intuition on what we consider to be the same thing over time. the
>> google website remains the google website even if they change the
>> design, same goes for the wikipedia page about google it remains the
>> wikipedia site about google (with the same URI) even after it was
>> changed, one never becomes the other.
>>
>>>
>>> You can't have it both ways, argue on intentionality for different names and then
>>> refuse to see that temporally different graphs would also then need different names.
>> I was talking about intensionality. Two terms have a same intension
>> only is in the same universe of evaluation and at the same point in
>> time they have the same extension.
>>
>>>
>>> ( Btw. there are good arguments that intentionally the local graph if it is a cache
>>> does not differ from the remote one. In any case if you pursue this too far you will
>>> find that you can never name any remote thing. )
>>>
>>>> I don't think that clerezza-490 need to be resolved urgently, but anyway we
>>>> should proceed issue by issue, and the best resolution of an issue is a minimal
>>>> resolution not one that tries to foresee and future issues.
>>>
>>> I tend to see logical consequences of an argument as being contained in the argument,
>>> and not being future issues that can be looked at later as somehow being distinct.
>> yes, but:
>> 1. analysing till the very bottom inevitably leads to paralysis.
>> 2. this inconsistent with your intuition based named change without discussion
>> 3. We have problems needing a fix (only to be as good as before your
>> patches) and you're not making a concrete proposal
>>
>>>
>>> Clerezza-490 that deals with different ways the server can present itself to other
>>> servers, is not of course something that needs to be implemented immediately. But it
>>> would be good that the naming solution we come up with can be extended to that case
>>> and to the temporal case.
>>>
>>> So I am invoking Clerezza-490 as something to help test the naming ideas being put
>>> forward here. This is a logical test if you will.
>> see above
>>
>>>
>>>>> So local graph naming schemes should take that into account, which is why I
>>>>> suggest that we have an API that can allow for extensibility here.
>>>> We have currently things and we are naming them badly.
>>>>
>>>> Prior to you r webproxy we had:
>>>> <webid-profile-url>.cache as name for the cache of the webprofile
>>>> and
>>>> <webid-profile-url> as uri for triples the user generated locally,
>>>> this can be seen as extensions to the remote profile with information
>>>> (like preferred language) that happen not to be in the remote profile
>>>>
>>>> which was consistent with local users who only had
>>>> <webid-profile-url> for the triples they control which include both
>>>> the regular profile as well
>>>
>>> yes, and both of those were not good solutions.
>>> The .cache solution is bound to create a problem if someone remotely has
>>> a URI named http://some.example/resource.cache
>>>
>>> It is bound to lead to nasty name clashes, with the same URI naming two different things.
>> right, I'm admitting it wasn't ideal - but I preffere the seldom
>> clashes to the ambiguity by design.
>>
>>>
>>> Remote URIs are named by remote resources, so it makes more sense to use the URI of the
>>> remote resource to name the graph of the remote resource. The remote resource was named
>>> by the owner of the resource. We should respect that.
>> <sarcasm>so we nshould not do caching, as the uri prefix http implies
>> a preferred method for retrieving the resource which is definitively
>> different than getting it out of a local tdb store</sarcasm>
>>
>>>
>>> If there are local additions to a remote graph, they should be given a local
>>> URI. There is nothing simpler than this solution it seems to me.
>>>
>>>>
>>>> Now <webid-profile-url> is the cache,
>>>
>>> You can look at it that way, or you can think of it as the name of the remote
>>> graph, with the contents being the cache of the remote graph.
>>>
>>> If you were to make the local graph available publicly, it would then of
>>> course need to have a local url tied into your namespace. Perhaps this is a good
>>> way to think of the distinction.
>>
>> I'm noty saying your proposal is absurd, but you introduced in a way
>> that breaks things an without discussion. now that I want to clean the
>> mess you start writing socio-philosophical essays
>>
>>>
>>>
>>>> not sure where additional
>>>> triples added locally get stored, i.e. where triples added to
>>>> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
>>>
>>>
>>> They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
>>>
>>> So currently as an initial proposal I put them in
>> as a proposal ok, but you changed something that was working without
>> dissusing the consequences this e.g. for permissions.
>>
>> <snip/>
>>> Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
>>>
>>> A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
>>>
>>> By giving apps access to name spaces you can also make sure that there won't be any clashes.
>> there is nothing that prevent application from making there own graphs
>> for user information.
>>
>>>
>>> now, that could be a reason for having URIs like
>>>
>>> mvn:/dev.net/application1/?user=webid...
>>>
>>> But then you see that applications on different servers will have name clashes too if they
>>> ever merge their databases.
>>>
>>> The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
>>>
>>>> I'm not saying the old naming was perfect but it worked in a somehow
>>>> consistent fashion for local and remote users.
>>>
>>> It was very confusing to me at least, as I point out in CLEREZZA-489.
>>>
>>> And it furthermore is inconsistent with your point above that remote graphs are
>>> intentionally different from the local version.
>>>
>>>> Now my application taht used this feature is now longer working.
>>>
>>> Well that is the problem of having an initial system that is broken.
>>> It will be easy to fix this, and we should fix it well, not do a half job of it,
>>> because this is a distributed naming problem.
>> I'm tired. I've nothing against a concrete counter proposal against
>> the one that started the tread, e.g. saying: "we must give every
>> instance a unique-id and this should be part of the
>> x-localinstance-uri"
>>
>>
>>>
>>>>
>>>>> in Clerezza-489 I wrote that one could describe each graph like this in a
>>>>> special Cache graph perhaps.
>>>>> :g202323 a :Graph;
>>>>> = { ... };
>>>>> :fetchedFrom <https://remote.com/>;
>>>>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>>>>> :representation <file:/tmp/repr/202323>;
>>>>> :httpMeta [ etag "sdfsdfsddfs";
>>>>> validTo "2012...."^^xsd:dateTime;
>>>>> ... redirected info?
>>>>> ] .
>>>>>
>>>>> :g202324 a :Graph;
>>>>> = { ... };
>>>>> :fetchedFrom <https://remote.com/>;
>>>>> :fetchedBy <http://farewellutopia.com/reto#me>;
>>>>> :representation <file:/tmp/repr/202324>;
>>>>> :httpMeta [ etag "ddfsdfsddfd";
>>>>> validTo "2012...."^^xsd:dateTime;
>>>>> ... redirected info?
>>>>> ] .
>>>>
>>>> If we had barketing in RDF and our tooling would support it the the
>>>> above might be somehow topical, answer to the question "how to name
>>>> this?" "don't name it".
>>>
>>> The above is just a way of writing the contents of the graph and the metadata
>>> in the same file. That is what the
>>>
>>> :g202323 = { ... }
>>>
>>> is about. You don't need any special tools for that. If you use Jena to get the graph
>>> named above you would get the content of the brackets. The point is that the content
>>> from
>> Also in jena the graphs have a name, very profane sequence of
>> characters this discussion was about. So in clerezza of in jena in the
>> metadata graph you have a name instead of {...} and for this name you
>> will get {...} from the named graph store.
>>
>>>
>>> :fetchedFrom ..
>>> :fetchedBy ...
>>>
>>> is not in the g202323 graph, but in a graph metadata graph.
>> obviously
>>>
>>>> Please lets proceed issue by issue and make
>>>> sure every brick we place is really solid and separate this from
>>>> visionary long term stuff.
>>>
>>> Ok, I hope you see that I introduced nothing new there. It's just an
>>> n3 notation that makes it easy to write things out in an e-mail.
>> an n3 notaions that omits exactly what this discussion is about,
>> namely my nameing proposal and your -1 gainst it.
>>
>>>
>>> So please consider that point again in that light.
>>>
>>>>>
>>>>> Then this API could use information from this graph to and information from
>>>>> the user's request
>>>>> to find the correct local graph he wants.
>>>> Still the local graph would have a name, probably - but as I said its
>>>> irrelevant. Lets deal with the issues at hand, you changed the names
>>>> of graph (which I agree didn't have the best possible names) with
>>>> names that I think are worse, lets find something we can agree upon.
>>>> (otherwise, please roll back to the version with the orginal names
>>>> till we find a consensus).
>>>
>>> Well I don't think rolling back would improve anything. I think clearly
>>> this was an improvement. But I do think we can do better.
>> It a mixture between improvements and deterioration. following the
>> right process avoids the deterioations
>>
>>
>>>
>>> So my thinking is that to reach consensus we can do this with an API, without
>>> deciding what precisely the names should be.
>> Stop: I disagree with your new names and we have problems because of
>> your name changes and now you dont want to decide about names?!
>>
>>> The best is just to lay out the
>>> requirements:
>>>
>>> 1. mapping from a remote URI to the URI understood by the local triple store
>>> and back. There should be no name clashes. It should be possible to easily extend
>>> to have agent views and temporal views.
>>>
>>> 2. method for applications to take hold of legitimate namespaces in such a way that
>>> a clash of names is not possible.
>>
>> If any proposal for changing names satisfies one of your criteria less
>> than the staus before the poposal your applying the argument to the
>> concrete proposal is welcome.
>>
>> Reto
>>
>>
>>>
>>>
>>> Henry
>>>
>>>
>>>>
>>>> Reto
>>>>
>>>>> Henry
>>>>> PS. Having said that one then may just wonder why local graphs should ever
>>>>> have anything other than
>>>>> local URLs, since every time someone made a copy of a local graph it would
>>>>> be different.
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>
> Social Web Architect
> http://bblfish.net/
>
>
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
I would like you first to read through the extensive mail I wrote, which took
me some time to write, and think things through.
Henry
On 14 May 2011, at 22:37, Reto Bachmann-Gmuer wrote:
> On Sat, May 14, 2011 at 7:54 PM, Henry Story <he...@bblfish.net> wrote:
>> Btw, I suppose I should say that I am not massively against the suggestion
>> you started this thread with. It is more than I am trying to explore this
>> more carefully, because it is an important discussion that deserves careful
>> thought.
> The careful procedure is to have tiny little issues which when
> resolved bring a tiny but undisputed improvement. Now with your
> resolution of CLEREZZA-463 I'm having massive problems and even if you
> think the status quo ante was fundamentally wrong I believe the
> graph-renaming you did makes things worse.
>
> I know that CLEREZZA-463 contains many real improvement. But it also
> introduce problems. And not just what you might consider a
> philosophical problem that names denote extensionally different things
> but also very practical ones.
>
> One major problem is the permission. We introduces
> WebIdBasedPermissionProvider and one implementation
> (UserGraphAcessPermissionProvider) used to provide readwrite access to
> the profile graph. Now this no longer works because you changed the
> names of graphs. Because of this and not because of a fundamentally
> broken architecture before your patch applications that used to work.
>
> Your -1 was against urn:x-localinstance:/cache/<remote-uri>
>
> The status quo ante was
>
> cache graph: <web-profile-uri>.cache
> profie-graph: <web-profile-uri>
>
> with the resolution of CLEREZZA-463 we have
>
> cache graph <web-profile-uri>
> profile graphs for local users: <web-profile-uri>
> profile graphs for remote users: <default-base-uri>/<web-profile-uri>
>
> you did change some names, probably just because of inconsistent
> changes things broke (UserGraphAcessPermissionProvider seems pointless
> right now). I don't want to
>
> and such that because of the renaming of graphs the
> UserGraphAcessPermissionProvider
>
> - The user has no longer the right to write to its own graph
> - Because the user graphs that is now (with your resolution of
> CLEREZZA-463) named like
> <http://localhost:8080/user/https://farewellutopia.com/user/me/profile>
>
> In my opinion to changed a suboptimal solution against quite a mess,
> now you argue against my solution to tidy things up because you are
> afraid of having a mess in one year.
>
> So please either accept my proposal which started this thread as
> something that is better than the status quo (i.e. retract your -1 so
> I can finally go back coding) or make a concrete proposal on how to
> name the different entities I've been suggesting names for or else
> revert the changes for CLEREZZA-463 (so that applications that used to
> work work again and we can start a proper development with little
> issues and patches that represent undisputed improvements.
>
>
> ==== what I consider important and relevant to current development
> ends here ====
>
>>
>> On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
>>
>>> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>>>> Reto wrote:
>>>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>>>> that I'm stating rather than arguing.
>>>> :-)
>>>>> The argument: they are different thing, both intensionally (cache and
>>>>> source) as in many case extensionally (triples may differ).
>>>>
>>>> in that sense I agree.
>>>> But then the other point I made is also true, and that is that different
>>>> users may get different
>>>> graphs back for the same remote resource. In fact those users may be the
>>>> same user at different times. Since those are all different graphs by your
>>>> definition above one should also give them different names.
>>> We do not have support for this yet and I think its a feature
>>> increasing complexity massively.
>>
>> You are dealing with an architectural problem which cannot just be dealt
>> with in stages. You need to look at the problem as a whole, or you will
>> just end up with the problem we are having right now. It is better to get this
>> issue cleared up now, than have a mess of graph names in one year, when a lot of
>> applications depend on this.
> This kind of against agile mantras and it seems to contrast very
> strongly to what you just did: you changed the names and now want a
> scientific study to change them again to solve the problems your
> namechange introduced.
>
>>
>> In any case it's not increasing anything massively, it is the logical
>> continuation of your point above.
> If you propose a patch which changes names and deliver good arguments
> why the new names are massively better and support future usecases
> without any disadvantage for addressing the current usecases than I'm
> sure this gets accepted, what you did is mix-in this namechange in a
> whole bunch of patches.
>
>>
>> Your argument was:
>>
>> "they [the remote and the locally fetched graph] are different thing, both
>> intensionally (cache and source) as in many case extensionally (triples may differ)."
>>
>> And so it follows that graphs sent at different times may also differ
>> extensionally and should have different names too.
>
> No, we are talking about MGraphs here. I know transtemporal identity
> is a hard problem philosophically yet in practice we have quite strong
> intuition on what we consider to be the same thing over time. the
> google website remains the google website even if they change the
> design, same goes for the wikipedia page about google it remains the
> wikipedia site about google (with the same URI) even after it was
> changed, one never becomes the other.
>
>>
>> You can't have it both ways, argue on intentionality for different names and then
>> refuse to see that temporally different graphs would also then need different names.
> I was talking about intensionality. Two terms have a same intension
> only is in the same universe of evaluation and at the same point in
> time they have the same extension.
>
>>
>> ( Btw. there are good arguments that intentionally the local graph if it is a cache
>> does not differ from the remote one. In any case if you pursue this too far you will
>> find that you can never name any remote thing. )
>>
>>> I don't think that clerezza-490 need to be resolved urgently, but anyway we
>>> should proceed issue by issue, and the best resolution of an issue is a minimal
>>> resolution not one that tries to foresee and future issues.
>>
>> I tend to see logical consequences of an argument as being contained in the argument,
>> and not being future issues that can be looked at later as somehow being distinct.
> yes, but:
> 1. analysing till the very bottom inevitably leads to paralysis.
> 2. this inconsistent with your intuition based named change without discussion
> 3. We have problems needing a fix (only to be as good as before your
> patches) and you're not making a concrete proposal
>
>>
>> Clerezza-490 that deals with different ways the server can present itself to other
>> servers, is not of course something that needs to be implemented immediately. But it
>> would be good that the naming solution we come up with can be extended to that case
>> and to the temporal case.
>>
>> So I am invoking Clerezza-490 as something to help test the naming ideas being put
>> forward here. This is a logical test if you will.
> see above
>
>>
>>>> So local graph naming schemes should take that into account, which is why I
>>>> suggest that we have an API that can allow for extensibility here.
>>> We have currently things and we are naming them badly.
>>>
>>> Prior to you r webproxy we had:
>>> <webid-profile-url>.cache as name for the cache of the webprofile
>>> and
>>> <webid-profile-url> as uri for triples the user generated locally,
>>> this can be seen as extensions to the remote profile with information
>>> (like preferred language) that happen not to be in the remote profile
>>>
>>> which was consistent with local users who only had
>>> <webid-profile-url> for the triples they control which include both
>>> the regular profile as well
>>
>> yes, and both of those were not good solutions.
>> The .cache solution is bound to create a problem if someone remotely has
>> a URI named http://some.example/resource.cache
>>
>> It is bound to lead to nasty name clashes, with the same URI naming two different things.
> right, I'm admitting it wasn't ideal - but I preffere the seldom
> clashes to the ambiguity by design.
>
>>
>> Remote URIs are named by remote resources, so it makes more sense to use the URI of the
>> remote resource to name the graph of the remote resource. The remote resource was named
>> by the owner of the resource. We should respect that.
> <sarcasm>so we nshould not do caching, as the uri prefix http implies
> a preferred method for retrieving the resource which is definitively
> different than getting it out of a local tdb store</sarcasm>
>
>>
>> If there are local additions to a remote graph, they should be given a local
>> URI. There is nothing simpler than this solution it seems to me.
>>
>>>
>>> Now <webid-profile-url> is the cache,
>>
>> You can look at it that way, or you can think of it as the name of the remote
>> graph, with the contents being the cache of the remote graph.
>>
>> If you were to make the local graph available publicly, it would then of
>> course need to have a local url tied into your namespace. Perhaps this is a good
>> way to think of the distinction.
>
> I'm noty saying your proposal is absurd, but you introduced in a way
> that breaks things an without discussion. now that I want to clean the
> mess you start writing socio-philosophical essays
>
>>
>>
>>> not sure where additional
>>> triples added locally get stored, i.e. where triples added to
>>> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
>>
>>
>> They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
>>
>> So currently as an initial proposal I put them in
> as a proposal ok, but you changed something that was working without
> dissusing the consequences this e.g. for permissions.
>
> <snip/>
>> Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
>>
>> A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
>>
>> By giving apps access to name spaces you can also make sure that there won't be any clashes.
> there is nothing that prevent application from making there own graphs
> for user information.
>
>>
>> now, that could be a reason for having URIs like
>>
>> mvn:/dev.net/application1/?user=webid...
>>
>> But then you see that applications on different servers will have name clashes too if they
>> ever merge their databases.
>>
>> The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
>>
>>> I'm not saying the old naming was perfect but it worked in a somehow
>>> consistent fashion for local and remote users.
>>
>> It was very confusing to me at least, as I point out in CLEREZZA-489.
>>
>> And it furthermore is inconsistent with your point above that remote graphs are
>> intentionally different from the local version.
>>
>>> Now my application taht used this feature is now longer working.
>>
>> Well that is the problem of having an initial system that is broken.
>> It will be easy to fix this, and we should fix it well, not do a half job of it,
>> because this is a distributed naming problem.
> I'm tired. I've nothing against a concrete counter proposal against
> the one that started the tread, e.g. saying: "we must give every
> instance a unique-id and this should be part of the
> x-localinstance-uri"
>
>
>>
>>>
>>>> in Clerezza-489 I wrote that one could describe each graph like this in a
>>>> special Cache graph perhaps.
>>>> :g202323 a :Graph;
>>>> = { ... };
>>>> :fetchedFrom <https://remote.com/>;
>>>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>>>> :representation <file:/tmp/repr/202323>;
>>>> :httpMeta [ etag "sdfsdfsddfs";
>>>> validTo "2012...."^^xsd:dateTime;
>>>> ... redirected info?
>>>> ] .
>>>>
>>>> :g202324 a :Graph;
>>>> = { ... };
>>>> :fetchedFrom <https://remote.com/>;
>>>> :fetchedBy <http://farewellutopia.com/reto#me>;
>>>> :representation <file:/tmp/repr/202324>;
>>>> :httpMeta [ etag "ddfsdfsddfd";
>>>> validTo "2012...."^^xsd:dateTime;
>>>> ... redirected info?
>>>> ] .
>>>
>>> If we had barketing in RDF and our tooling would support it the the
>>> above might be somehow topical, answer to the question "how to name
>>> this?" "don't name it".
>>
>> The above is just a way of writing the contents of the graph and the metadata
>> in the same file. That is what the
>>
>> :g202323 = { ... }
>>
>> is about. You don't need any special tools for that. If you use Jena to get the graph
>> named above you would get the content of the brackets. The point is that the content
>> from
> Also in jena the graphs have a name, very profane sequence of
> characters this discussion was about. So in clerezza of in jena in the
> metadata graph you have a name instead of {...} and for this name you
> will get {...} from the named graph store.
>
>>
>> :fetchedFrom ..
>> :fetchedBy ...
>>
>> is not in the g202323 graph, but in a graph metadata graph.
> obviously
>>
>>> Please lets proceed issue by issue and make
>>> sure every brick we place is really solid and separate this from
>>> visionary long term stuff.
>>
>> Ok, I hope you see that I introduced nothing new there. It's just an
>> n3 notation that makes it easy to write things out in an e-mail.
> an n3 notaions that omits exactly what this discussion is about,
> namely my nameing proposal and your -1 gainst it.
>
>>
>> So please consider that point again in that light.
>>
>>>>
>>>> Then this API could use information from this graph to and information from
>>>> the user's request
>>>> to find the correct local graph he wants.
>>> Still the local graph would have a name, probably - but as I said its
>>> irrelevant. Lets deal with the issues at hand, you changed the names
>>> of graph (which I agree didn't have the best possible names) with
>>> names that I think are worse, lets find something we can agree upon.
>>> (otherwise, please roll back to the version with the orginal names
>>> till we find a consensus).
>>
>> Well I don't think rolling back would improve anything. I think clearly
>> this was an improvement. But I do think we can do better.
> It a mixture between improvements and deterioration. following the
> right process avoids the deterioations
>
>
>>
>> So my thinking is that to reach consensus we can do this with an API, without
>> deciding what precisely the names should be.
> Stop: I disagree with your new names and we have problems because of
> your name changes and now you dont want to decide about names?!
>
>> The best is just to lay out the
>> requirements:
>>
>> 1. mapping from a remote URI to the URI understood by the local triple store
>> and back. There should be no name clashes. It should be possible to easily extend
>> to have agent views and temporal views.
>>
>> 2. method for applications to take hold of legitimate namespaces in such a way that
>> a clash of names is not possible.
>
> If any proposal for changing names satisfies one of your criteria less
> than the staus before the poposal your applying the argument to the
> concrete proposal is welcome.
>
> Reto
>
>
>>
>>
>> Henry
>>
>>
>>>
>>> Reto
>>>
>>>> Henry
>>>> PS. Having said that one then may just wonder why local graphs should ever
>>>> have anything other than
>>>> local URLs, since every time someone made a copy of a local graph it would
>>>> be different.
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 14 May 2011, at 22:37, Reto Bachmann-Gmuer wrote:
> On Sat, May 14, 2011 at 7:54 PM, Henry Story <he...@bblfish.net> wrote:
>> Btw, I suppose I should say that I am not massively against the suggestion
>> you started this thread with. It is more than I am trying to explore this
>> more carefully, because it is an important discussion that deserves careful
>> thought.
> The careful procedure is to have tiny little issues which when
> resolved bring a tiny but undisputed improvement. Now with your
> resolution of CLEREZZA-463 I'm having massive problems and even if you
> think the status quo ante was fundamentally wrong I believe the
> graph-renaming you did makes things worse.
>
> I know that CLEREZZA-463 contains many real improvement. But it also
> introduce problems. And not just what you might consider a
> philosophical problem that names denote extensionally different things
> but also very practical ones.
>
> One major problem is the permission. We introduces
> WebIdBasedPermissionProvider and one implementation
> (UserGraphAcessPermissionProvider) used to provide readwrite access to
> the profile graph. Now this no longer works because you changed the
> names of graphs. Because of this and not because of a fundamentally
> broken architecture before your patch applications that used to work.
How fundamental is this problem? And how many lines of code would
it take to change it?
> Your -1 was against urn:x-localinstance:/cache/<remote-uri>
yes, because I don't see how it is better than just
<remote-uri>
Or at least I would like to hear the argument for it. Where
does this issue pop up for you currently?
>
> The status quo ante was
>
> cache graph: <web-profile-uri>.cache
> profie-graph: <web-profile-uri>
yes and that clearly is not such a good idea for two reasons:
1. you are creating a name (.cache) for a remote URI in a space you do not control
2. there could be a remote url with the .cache url and you end up having name clashes
3. you are using a remote URL for the name of a graph you are controlling
>
> with the resolution of CLEREZZA-463 we have
>
> cache graph <web-profile-uri>
> profile graphs for local users: <web-profile-uri>
yes, so that works nicely. The URI for the information about the user is AT
the URI.
> profile graphs for remote users: <default-base-uri>/<web-profile-uri>
the local extra information is there yes. What is the problem?
>
> you did change some names, probably just because of inconsistent
> changes things broke (UserGraphAcessPermissionProvider seems pointless
> right now). I don't want to and such that because of the renaming of graphs the
> UserGraphAcessPermissionProvider
>
> - The user has no longer the right to write to its own graph
> - Because the user graphs that is now (with your resolution of
> CLEREZZA-463) named like
> <http://localhost:8080/user/https://farewellutopia.com/user/me/profile>
> In my opinion to changed a suboptimal solution against quite a mess,
where is the mess?
I read the above as pointing to an issue needing fixing in the access control code.
> now you argue against my solution to tidy things up because you are
> afraid of having a mess in one year.
why is your solution a tidying up of things? What issue are you really solving?
>
> So please either accept my proposal which started this thread as
> something that is better than the status quo
The way things are now is ok it seems. I don't see that you have an
argument other than that there is a bug in access control for changing
things.
> (i.e. retract your -1 so
> I can finally go back coding)
you can already go and code. The question is how can what you do and anyone else does
lead to name clashes I suppose, which is what we should try to avoid.
> or make a concrete proposal on how to
> name the different entities I've been suggesting names for
I have. the way things are now makes sense to me.
> or else revert the changes for CLEREZZA-463 (so that applications that used to
> work work again and we can start a proper development with little
> issues and patches that represent undisputed improvements.
Well what about fixing the access control then?
>
> ==== what I consider important and relevant to current development
> ends here ====
>
>>
>> On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
>>
>>> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>>>> Reto wrote:
>>>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>>>> that I'm stating rather than arguing.
>>>> :-)
>>>>> The argument: they are different thing, both intensionally (cache and
>>>>> source) as in many case extensionally (triples may differ).
>>>>
>>>> in that sense I agree.
>>>> But then the other point I made is also true, and that is that different
>>>> users may get different
>>>> graphs back for the same remote resource. In fact those users may be the
>>>> same user at different times. Since those are all different graphs by your
>>>> definition above one should also give them different names.
>>> We do not have support for this yet and I think its a feature
>>> increasing complexity massively.
>>
>> You are dealing with an architectural problem which cannot just be dealt
>> with in stages. You need to look at the problem as a whole, or you will
>> just end up with the problem we are having right now. It is better to get this
>> issue cleared up now, than have a mess of graph names in one year, when a lot of
>> applications depend on this.
> This kind of against agile mantras and it seems to contrast very
> strongly to what you just did: you changed the names and now want a
> scientific study to change them again to solve the problems your
> namechange introduced.
>
>>
>> In any case it's not increasing anything massively, it is the logical
>> continuation of your point above.
> If you propose a patch which changes names and deliver good arguments
> why the new names are massively better and support future usecases
> without any disadvantage for addressing the current usecases than I'm
> sure this gets accepted, what you did is mix-in this namechange in a
> whole bunch of patches.
>
>>
>> Your argument was:
>>
>> "they [the remote and the locally fetched graph] are different thing, both
>> intensionally (cache and source) as in many case extensionally (triples may differ)."
>>
>> And so it follows that graphs sent at different times may also differ
>> extensionally and should have different names too.
>
> No, we are talking about MGraphs here. I know transtemporal identity
> is a hard problem philosophically yet in practice we have quite strong
> intuition on what we consider to be the same thing over time. the
> google website remains the google website even if they change the
> design, same goes for the wikipedia page about google it remains the
> wikipedia site about google (with the same URI) even after it was
> changed, one never becomes the other.
>
>>
>> You can't have it both ways, argue on intentionality for different names and then
>> refuse to see that temporally different graphs would also then need different names.
> I was talking about intensionality. Two terms have a same intension
> only is in the same universe of evaluation and at the same point in
> time they have the same extension.
>
>>
>> ( Btw. there are good arguments that intentionally the local graph if it is a cache
>> does not differ from the remote one. In any case if you pursue this too far you will
>> find that you can never name any remote thing. )
>>
>>> I don't think that clerezza-490 need to be resolved urgently, but anyway we
>>> should proceed issue by issue, and the best resolution of an issue is a minimal
>>> resolution not one that tries to foresee and future issues.
>>
>> I tend to see logical consequences of an argument as being contained in the argument,
>> and not being future issues that can be looked at later as somehow being distinct.
> yes, but:
> 1. analysing till the very bottom inevitably leads to paralysis.
> 2. this inconsistent with your intuition based named change without discussion
> 3. We have problems needing a fix (only to be as good as before your
> patches) and you're not making a concrete proposal
>
>>
>> Clerezza-490 that deals with different ways the server can present itself to other
>> servers, is not of course something that needs to be implemented immediately. But it
>> would be good that the naming solution we come up with can be extended to that case
>> and to the temporal case.
>>
>> So I am invoking Clerezza-490 as something to help test the naming ideas being put
>> forward here. This is a logical test if you will.
> see above
>
>>
>>>> So local graph naming schemes should take that into account, which is why I
>>>> suggest that we have an API that can allow for extensibility here.
>>> We have currently things and we are naming them badly.
>>>
>>> Prior to you r webproxy we had:
>>> <webid-profile-url>.cache as name for the cache of the webprofile
>>> and
>>> <webid-profile-url> as uri for triples the user generated locally,
>>> this can be seen as extensions to the remote profile with information
>>> (like preferred language) that happen not to be in the remote profile
>>>
>>> which was consistent with local users who only had
>>> <webid-profile-url> for the triples they control which include both
>>> the regular profile as well
>>
>> yes, and both of those were not good solutions.
>> The .cache solution is bound to create a problem if someone remotely has
>> a URI named http://some.example/resource.cache
>>
>> It is bound to lead to nasty name clashes, with the same URI naming two different things.
> right, I'm admitting it wasn't ideal - but I preffere the seldom
> clashes to the ambiguity by design.
>
>>
>> Remote URIs are named by remote resources, so it makes more sense to use the URI of the
>> remote resource to name the graph of the remote resource. The remote resource was named
>> by the owner of the resource. We should respect that.
> <sarcasm>so we nshould not do caching, as the uri prefix http implies
> a preferred method for retrieving the resource which is definitively
> different than getting it out of a local tdb store</sarcasm>
>
>>
>> If there are local additions to a remote graph, they should be given a local
>> URI. There is nothing simpler than this solution it seems to me.
>>
>>>
>>> Now <webid-profile-url> is the cache,
>>
>> You can look at it that way, or you can think of it as the name of the remote
>> graph, with the contents being the cache of the remote graph.
>>
>> If you were to make the local graph available publicly, it would then of
>> course need to have a local url tied into your namespace. Perhaps this is a good
>> way to think of the distinction.
>
> I'm noty saying your proposal is absurd, but you introduced in a way
> that breaks things an without discussion. now that I want to clean the
> mess you start writing socio-philosophical essays
>
>>
>>
>>> not sure where additional
>>> triples added locally get stored, i.e. where triples added to
>>> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
>>
>>
>> They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
>>
>> So currently as an initial proposal I put them in
> as a proposal ok, but you changed something that was working without
> dissusing the consequences this e.g. for permissions.
>
> <snip/>
>> Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
>>
>> A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
>>
>> By giving apps access to name spaces you can also make sure that there won't be any clashes.
> there is nothing that prevent application from making there own graphs
> for user information.
>
>>
>> now, that could be a reason for having URIs like
>>
>> mvn:/dev.net/application1/?user=webid...
>>
>> But then you see that applications on different servers will have name clashes too if they
>> ever merge their databases.
>>
>> The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
>>
>>> I'm not saying the old naming was perfect but it worked in a somehow
>>> consistent fashion for local and remote users.
>>
>> It was very confusing to me at least, as I point out in CLEREZZA-489.
>>
>> And it furthermore is inconsistent with your point above that remote graphs are
>> intentionally different from the local version.
>>
>>> Now my application taht used this feature is now longer working.
>>
>> Well that is the problem of having an initial system that is broken.
>> It will be easy to fix this, and we should fix it well, not do a half job of it,
>> because this is a distributed naming problem.
> I'm tired. I've nothing against a concrete counter proposal against
> the one that started the tread, e.g. saying: "we must give every
> instance a unique-id and this should be part of the
> x-localinstance-uri"
>
>
>>
>>>
>>>> in Clerezza-489 I wrote that one could describe each graph like this in a
>>>> special Cache graph perhaps.
>>>> :g202323 a :Graph;
>>>> = { ... };
>>>> :fetchedFrom <https://remote.com/>;
>>>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>>>> :representation <file:/tmp/repr/202323>;
>>>> :httpMeta [ etag "sdfsdfsddfs";
>>>> validTo "2012...."^^xsd:dateTime;
>>>> ... redirected info?
>>>> ] .
>>>>
>>>> :g202324 a :Graph;
>>>> = { ... };
>>>> :fetchedFrom <https://remote.com/>;
>>>> :fetchedBy <http://farewellutopia.com/reto#me>;
>>>> :representation <file:/tmp/repr/202324>;
>>>> :httpMeta [ etag "ddfsdfsddfd";
>>>> validTo "2012...."^^xsd:dateTime;
>>>> ... redirected info?
>>>> ] .
>>>
>>> If we had barketing in RDF and our tooling would support it the the
>>> above might be somehow topical, answer to the question "how to name
>>> this?" "don't name it".
>>
>> The above is just a way of writing the contents of the graph and the metadata
>> in the same file. That is what the
>>
>> :g202323 = { ... }
>>
>> is about. You don't need any special tools for that. If you use Jena to get the graph
>> named above you would get the content of the brackets. The point is that the content
>> from
> Also in jena the graphs have a name, very profane sequence of
> characters this discussion was about. So in clerezza of in jena in the
> metadata graph you have a name instead of {...} and for this name you
> will get {...} from the named graph store.
>
>>
>> :fetchedFrom ..
>> :fetchedBy ...
>>
>> is not in the g202323 graph, but in a graph metadata graph.
> obviously
>>
>>> Please lets proceed issue by issue and make
>>> sure every brick we place is really solid and separate this from
>>> visionary long term stuff.
>>
>> Ok, I hope you see that I introduced nothing new there. It's just an
>> n3 notation that makes it easy to write things out in an e-mail.
> an n3 notaions that omits exactly what this discussion is about,
> namely my nameing proposal and your -1 gainst it.
>
>>
>> So please consider that point again in that light.
>>
>>>>
>>>> Then this API could use information from this graph to and information from
>>>> the user's request
>>>> to find the correct local graph he wants.
>>> Still the local graph would have a name, probably - but as I said its
>>> irrelevant. Lets deal with the issues at hand, you changed the names
>>> of graph (which I agree didn't have the best possible names) with
>>> names that I think are worse, lets find something we can agree upon.
>>> (otherwise, please roll back to the version with the orginal names
>>> till we find a consensus).
>>
>> Well I don't think rolling back would improve anything. I think clearly
>> this was an improvement. But I do think we can do better.
> It a mixture between improvements and deterioration. following the
> right process avoids the deterioations
>
>
>>
>> So my thinking is that to reach consensus we can do this with an API, without
>> deciding what precisely the names should be.
> Stop: I disagree with your new names and we have problems because of
> your name changes and now you dont want to decide about names?!
>
>> The best is just to lay out the
>> requirements:
>>
>> 1. mapping from a remote URI to the URI understood by the local triple store
>> and back. There should be no name clashes. It should be possible to easily extend
>> to have agent views and temporal views.
>>
>> 2. method for applications to take hold of legitimate namespaces in such a way that
>> a clash of names is not possible.
>
> If any proposal for changing names satisfies one of your criteria less
> than the staus before the poposal your applying the argument to the
> concrete proposal is welcome.
>
> Reto
>
>
>>
>>
>> Henry
>>
>>
>>>
>>> Reto
>>>
>>>> Henry
>>>> PS. Having said that one then may just wonder why local graphs should ever
>>>> have anything other than
>>>> local URLs, since every time someone made a copy of a local graph it would
>>>> be different.
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
On Sat, May 14, 2011 at 7:54 PM, Henry Story <he...@bblfish.net> wrote:
> Btw, I suppose I should say that I am not massively against the suggestion
> you started this thread with. It is more than I am trying to explore this
> more carefully, because it is an important discussion that deserves careful
> thought.
The careful procedure is to have tiny little issues which when
resolved bring a tiny but undisputed improvement. Now with your
resolution of CLEREZZA-463 I'm having massive problems and even if you
think the status quo ante was fundamentally wrong I believe the
graph-renaming you did makes things worse.
I know that CLEREZZA-463 contains many real improvement. But it also
introduce problems. And not just what you might consider a
philosophical problem that names denote extensionally different things
but also very practical ones.
One major problem is the permission. We introduces
WebIdBasedPermissionProvider and one implementation
(UserGraphAcessPermissionProvider) used to provide readwrite access to
the profile graph. Now this no longer works because you changed the
names of graphs. Because of this and not because of a fundamentally
broken architecture before your patch applications that used to work.
Your -1 was against urn:x-localinstance:/cache/<remote-uri>
The status quo ante was
cache graph: <web-profile-uri>.cache
profie-graph: <web-profile-uri>
with the resolution of CLEREZZA-463 we have
cache graph <web-profile-uri>
profile graphs for local users: <web-profile-uri>
profile graphs for remote users: <default-base-uri>/<web-profile-uri>
you did change some names, probably just because of inconsistent
changes things broke (UserGraphAcessPermissionProvider seems pointless
right now). I don't want to
and such that because of the renaming of graphs the
UserGraphAcessPermissionProvider
- The user has no longer the right to write to its own graph
- Because the user graphs that is now (with your resolution of
CLEREZZA-463) named like
<http://localhost:8080/user/https://farewellutopia.com/user/me/profile>
In my opinion to changed a suboptimal solution against quite a mess,
now you argue against my solution to tidy things up because you are
afraid of having a mess in one year.
So please either accept my proposal which started this thread as
something that is better than the status quo (i.e. retract your -1 so
I can finally go back coding) or make a concrete proposal on how to
name the different entities I've been suggesting names for or else
revert the changes for CLEREZZA-463 (so that applications that used to
work work again and we can start a proper development with little
issues and patches that represent undisputed improvements.
==== what I consider important and relevant to current development
ends here ====
>
> On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
>
>> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>>> Reto wrote:
>>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>>> that I'm stating rather than arguing.
>>> :-)
>>>> The argument: they are different thing, both intensionally (cache and
>>>> source) as in many case extensionally (triples may differ).
>>>
>>> in that sense I agree.
>>> But then the other point I made is also true, and that is that different
>>> users may get different
>>> graphs back for the same remote resource. In fact those users may be the
>>> same user at different times. Since those are all different graphs by your
>>> definition above one should also give them different names.
>> We do not have support for this yet and I think its a feature
>> increasing complexity massively.
>
> You are dealing with an architectural problem which cannot just be dealt
> with in stages. You need to look at the problem as a whole, or you will
> just end up with the problem we are having right now. It is better to get this
> issue cleared up now, than have a mess of graph names in one year, when a lot of
> applications depend on this.
This kind of against agile mantras and it seems to contrast very
strongly to what you just did: you changed the names and now want a
scientific study to change them again to solve the problems your
namechange introduced.
>
> In any case it's not increasing anything massively, it is the logical
> continuation of your point above.
If you propose a patch which changes names and deliver good arguments
why the new names are massively better and support future usecases
without any disadvantage for addressing the current usecases than I'm
sure this gets accepted, what you did is mix-in this namechange in a
whole bunch of patches.
>
> Your argument was:
>
> "they [the remote and the locally fetched graph] are different thing, both
> intensionally (cache and source) as in many case extensionally (triples may differ)."
>
> And so it follows that graphs sent at different times may also differ
> extensionally and should have different names too.
No, we are talking about MGraphs here. I know transtemporal identity
is a hard problem philosophically yet in practice we have quite strong
intuition on what we consider to be the same thing over time. the
google website remains the google website even if they change the
design, same goes for the wikipedia page about google it remains the
wikipedia site about google (with the same URI) even after it was
changed, one never becomes the other.
>
> You can't have it both ways, argue on intentionality for different names and then
> refuse to see that temporally different graphs would also then need different names.
I was talking about intensionality. Two terms have a same intension
only is in the same universe of evaluation and at the same point in
time they have the same extension.
>
> ( Btw. there are good arguments that intentionally the local graph if it is a cache
> does not differ from the remote one. In any case if you pursue this too far you will
> find that you can never name any remote thing. )
>
>> I don't think that clerezza-490 need to be resolved urgently, but anyway we
>> should proceed issue by issue, and the best resolution of an issue is a minimal
>> resolution not one that tries to foresee and future issues.
>
> I tend to see logical consequences of an argument as being contained in the argument,
> and not being future issues that can be looked at later as somehow being distinct.
yes, but:
1. analysing till the very bottom inevitably leads to paralysis.
2. this inconsistent with your intuition based named change without discussion
3. We have problems needing a fix (only to be as good as before your
patches) and you're not making a concrete proposal
>
> Clerezza-490 that deals with different ways the server can present itself to other
> servers, is not of course something that needs to be implemented immediately. But it
> would be good that the naming solution we come up with can be extended to that case
> and to the temporal case.
>
> So I am invoking Clerezza-490 as something to help test the naming ideas being put
> forward here. This is a logical test if you will.
see above
>
>>> So local graph naming schemes should take that into account, which is why I
>>> suggest that we have an API that can allow for extensibility here.
>> We have currently things and we are naming them badly.
>>
>> Prior to you r webproxy we had:
>> <webid-profile-url>.cache as name for the cache of the webprofile
>> and
>> <webid-profile-url> as uri for triples the user generated locally,
>> this can be seen as extensions to the remote profile with information
>> (like preferred language) that happen not to be in the remote profile
>>
>> which was consistent with local users who only had
>> <webid-profile-url> for the triples they control which include both
>> the regular profile as well
>
> yes, and both of those were not good solutions.
> The .cache solution is bound to create a problem if someone remotely has
> a URI named http://some.example/resource.cache
>
> It is bound to lead to nasty name clashes, with the same URI naming two different things.
right, I'm admitting it wasn't ideal - but I preffere the seldom
clashes to the ambiguity by design.
>
> Remote URIs are named by remote resources, so it makes more sense to use the URI of the
> remote resource to name the graph of the remote resource. The remote resource was named
> by the owner of the resource. We should respect that.
<sarcasm>so we nshould not do caching, as the uri prefix http implies
a preferred method for retrieving the resource which is definitively
different than getting it out of a local tdb store</sarcasm>
>
> If there are local additions to a remote graph, they should be given a local
> URI. There is nothing simpler than this solution it seems to me.
>
>>
>> Now <webid-profile-url> is the cache,
>
> You can look at it that way, or you can think of it as the name of the remote
> graph, with the contents being the cache of the remote graph.
>
> If you were to make the local graph available publicly, it would then of
> course need to have a local url tied into your namespace. Perhaps this is a good
> way to think of the distinction.
I'm noty saying your proposal is absurd, but you introduced in a way
that breaks things an without discussion. now that I want to clean the
mess you start writing socio-philosophical essays
>
>
>> not sure where additional
>> triples added locally get stored, i.e. where triples added to
>> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
>
>
> They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
>
> So currently as an initial proposal I put them in
as a proposal ok, but you changed something that was working without
dissusing the consequences this e.g. for permissions.
<snip/>
> Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
>
> A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
>
> By giving apps access to name spaces you can also make sure that there won't be any clashes.
there is nothing that prevent application from making there own graphs
for user information.
>
> now, that could be a reason for having URIs like
>
> mvn:/dev.net/application1/?user=webid...
>
> But then you see that applications on different servers will have name clashes too if they
> ever merge their databases.
>
> The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
>
>> I'm not saying the old naming was perfect but it worked in a somehow
>> consistent fashion for local and remote users.
>
> It was very confusing to me at least, as I point out in CLEREZZA-489.
>
> And it furthermore is inconsistent with your point above that remote graphs are
> intentionally different from the local version.
>
>> Now my application taht used this feature is now longer working.
>
> Well that is the problem of having an initial system that is broken.
> It will be easy to fix this, and we should fix it well, not do a half job of it,
> because this is a distributed naming problem.
I'm tired. I've nothing against a concrete counter proposal against
the one that started the tread, e.g. saying: "we must give every
instance a unique-id and this should be part of the
x-localinstance-uri"
>
>>
>>> in Clerezza-489 I wrote that one could describe each graph like this in a
>>> special Cache graph perhaps.
>>> :g202323 a :Graph;
>>> = { ... };
>>> :fetchedFrom <https://remote.com/>;
>>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>>> :representation <file:/tmp/repr/202323>;
>>> :httpMeta [ etag "sdfsdfsddfs";
>>> validTo "2012...."^^xsd:dateTime;
>>> ... redirected info?
>>> ] .
>>>
>>> :g202324 a :Graph;
>>> = { ... };
>>> :fetchedFrom <https://remote.com/>;
>>> :fetchedBy <http://farewellutopia.com/reto#me>;
>>> :representation <file:/tmp/repr/202324>;
>>> :httpMeta [ etag "ddfsdfsddfd";
>>> validTo "2012...."^^xsd:dateTime;
>>> ... redirected info?
>>> ] .
>>
>> If we had barketing in RDF and our tooling would support it the the
>> above might be somehow topical, answer to the question "how to name
>> this?" "don't name it".
>
> The above is just a way of writing the contents of the graph and the metadata
> in the same file. That is what the
>
> :g202323 = { ... }
>
> is about. You don't need any special tools for that. If you use Jena to get the graph
> named above you would get the content of the brackets. The point is that the content
> from
Also in jena the graphs have a name, very profane sequence of
characters this discussion was about. So in clerezza of in jena in the
metadata graph you have a name instead of {...} and for this name you
will get {...} from the named graph store.
>
> :fetchedFrom ..
> :fetchedBy ...
>
> is not in the g202323 graph, but in a graph metadata graph.
obviously
>
>> Please lets proceed issue by issue and make
>> sure every brick we place is really solid and separate this from
>> visionary long term stuff.
>
> Ok, I hope you see that I introduced nothing new there. It's just an
> n3 notation that makes it easy to write things out in an e-mail.
an n3 notaions that omits exactly what this discussion is about,
namely my nameing proposal and your -1 gainst it.
>
> So please consider that point again in that light.
>
>>>
>>> Then this API could use information from this graph to and information from
>>> the user's request
>>> to find the correct local graph he wants.
>> Still the local graph would have a name, probably - but as I said its
>> irrelevant. Lets deal with the issues at hand, you changed the names
>> of graph (which I agree didn't have the best possible names) with
>> names that I think are worse, lets find something we can agree upon.
>> (otherwise, please roll back to the version with the orginal names
>> till we find a consensus).
>
> Well I don't think rolling back would improve anything. I think clearly
> this was an improvement. But I do think we can do better.
It a mixture between improvements and deterioration. following the
right process avoids the deterioations
>
> So my thinking is that to reach consensus we can do this with an API, without
> deciding what precisely the names should be.
Stop: I disagree with your new names and we have problems because of
your name changes and now you dont want to decide about names?!
> The best is just to lay out the
> requirements:
>
> 1. mapping from a remote URI to the URI understood by the local triple store
> and back. There should be no name clashes. It should be possible to easily extend
> to have agent views and temporal views.
>
> 2. method for applications to take hold of legitimate namespaces in such a way that
> a clash of names is not possible.
If any proposal for changing names satisfies one of your criteria less
than the staus before the poposal your applying the argument to the
concrete proposal is welcome.
Reto
>
>
> Henry
>
>
>>
>> Reto
>>
>>> Henry
>>> PS. Having said that one then may just wonder why local graphs should ever
>>> have anything other than
>>> local URLs, since every time someone made a copy of a local graph it would
>>> be different.
>
> Social Web Architect
> http://bblfish.net/
>
>
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
Btw, I suppose I should say that I am not massively against the suggestion
you started this thread with. It is more than I am trying to explore this
more carefully, because it is an important discussion that deserves careful
thought.
On 14 May 2011, at 17:09, Reto Bachmann-Gmuer wrote:
> On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
>> Reto wrote:
>>> Clerrezza-489 and you also quote may statement of 463. okay, you might say
>>> that I'm stating rather than arguing.
>> :-)
>>> The argument: they are different thing, both intensionally (cache and
>>> source) as in many case extensionally (triples may differ).
>>
>> in that sense I agree.
>> But then the other point I made is also true, and that is that different
>> users may get different
>> graphs back for the same remote resource. In fact those users may be the
>> same user at different times. Since those are all different graphs by your
>> definition above one should also give them different names.
> We do not have support for this yet and I think its a feature
> increasing complexity massively.
You are dealing with an architectural problem which cannot just be dealt
with in stages. You need to look at the problem as a whole, or you will
just end up with the problem we are having right now. It is better to get this
issue cleared up now, than have a mess of graph names in one year, when a lot of
applications depend on this.
In any case it's not increasing anything massively, it is the logical
continuation of your point above.
Your argument was:
"they [the remote and the locally fetched graph] are different thing, both
intensionally (cache and source) as in many case extensionally (triples may differ)."
And so it follows that graphs sent at different times may also differ
extensionally and should have different names too.
You can't have it both ways, argue on intentionality for different names and then
refuse to see that temporally different graphs would also then need different names.
( Btw. there are good arguments that intentionally the local graph if it is a cache
does not differ from the remote one. In any case if you pursue this too far you will
find that you can never name any remote thing. )
> I don't think that clerezza-490 need to be resolved urgently, but anyway we
> should proceed issue by issue, and the best resolution of an issue is a minimal
> resolution not one that tries to foresee and future issues.
I tend to see logical consequences of an argument as being contained in the argument,
and not being future issues that can be looked at later as somehow being distinct.
Clerezza-490 that deals with different ways the server can present itself to other
servers, is not of course something that needs to be implemented immediately. But it
would be good that the naming solution we come up with can be extended to that case
and to the temporal case.
So I am invoking Clerezza-490 as something to help test the naming ideas being put
forward here. This is a logical test if you will.
>> So local graph naming schemes should take that into account, which is why I
>> suggest that we have an API that can allow for extensibility here.
> We have currently things and we are naming them badly.
>
> Prior to you r webproxy we had:
> <webid-profile-url>.cache as name for the cache of the webprofile
> and
> <webid-profile-url> as uri for triples the user generated locally,
> this can be seen as extensions to the remote profile with information
> (like preferred language) that happen not to be in the remote profile
>
> which was consistent with local users who only had
> <webid-profile-url> for the triples they control which include both
> the regular profile as well
yes, and both of those were not good solutions.
The .cache solution is bound to create a problem if someone remotely has
a URI named http://some.example/resource.cache
It is bound to lead to nasty name clashes, with the same URI naming two different things.
Remote URIs are named by remote resources, so it makes more sense to use the URI of the
remote resource to name the graph of the remote resource. The remote resource was named
by the owner of the resource. We should respect that.
If there are local additions to a remote graph, they should be given a local
URI. There is nothing simpler than this solution it seems to me.
>
> Now <webid-profile-url> is the cache,
You can look at it that way, or you can think of it as the name of the remote
graph, with the contents being the cache of the remote graph.
If you were to make the local graph available publicly, it would then of
course need to have a local url tied into your namespace. Perhaps this is a good
way to think of the distinction.
> not sure where additional
> triples added locally get stored, i.e. where triples added to
> webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
They should be stored in graph names with a local URL clearly since these are being stored by a local agent. And I think it will be application specific what the names of those graphs should be.
So currently as an initial proposal I put them in
{local service name}/user/{remoteWebID}
eg: http://bblfish.net/user/http://reto.org/#me
(though that needs to be URLEncoded.)
This makes sense. If you have local info for the user admin you would put it in
http://bblfish.net/user/admin
Now imagine there are 2 or 3 applications on a clerezza instance, that a remote user with his WebID uses. There is no reason these applications should be putting all the information they generate for that user in the same local graph.
A banking graph should put banking info in its graph and a blogging graph into its graph. The way to do this is to give applications - like users - access to namespaces. Perhaps the bank application that was given control of the /bank namespace could coin graphs for remote users in that space, eg /bank/id/{remoteWebID} and the blogging one in /blog/id?{remoteWebID} .
By giving apps access to name spaces you can also make sure that there won't be any clashes.
now, that could be a reason for having URIs like
mvn:/dev.net/application1/?user=webid...
But then you see that applications on different servers will have name clashes too if they
ever merge their databases.
The advantage of using the local published name is that this then would allow simple dumps of databases and their merging in remote databases without clashes.
> I'm not saying the old naming was perfect but it worked in a somehow
> consistent fashion for local and remote users.
It was very confusing to me at least, as I point out in CLEREZZA-489.
And it furthermore is inconsistent with your point above that remote graphs are
intentionally different from the local version.
> Now my application taht used this feature is now longer working.
Well that is the problem of having an initial system that is broken.
It will be easy to fix this, and we should fix it well, not do a half job of it,
because this is a distributed naming problem.
>
>> in Clerezza-489 I wrote that one could describe each graph like this in a
>> special Cache graph perhaps.
>> :g202323 a :Graph;
>> = { ... };
>> :fetchedFrom <https://remote.com/>;
>> :fetchedBy <http://bblfish.net/people/henry/card#me>;
>> :representation <file:/tmp/repr/202323>;
>> :httpMeta [ etag "sdfsdfsddfs";
>> validTo "2012...."^^xsd:dateTime;
>> ... redirected info?
>> ] .
>>
>> :g202324 a :Graph;
>> = { ... };
>> :fetchedFrom <https://remote.com/>;
>> :fetchedBy <http://farewellutopia.com/reto#me>;
>> :representation <file:/tmp/repr/202324>;
>> :httpMeta [ etag "ddfsdfsddfd";
>> validTo "2012...."^^xsd:dateTime;
>> ... redirected info?
>> ] .
>
> If we had barketing in RDF and our tooling would support it the the
> above might be somehow topical, answer to the question "how to name
> this?" "don't name it".
The above is just a way of writing the contents of the graph and the metadata
in the same file. That is what the
:g202323 = { ... }
is about. You don't need any special tools for that. If you use Jena to get the graph
named above you would get the content of the brackets. The point is that the content
from
:fetchedFrom ..
:fetchedBy ...
is not in the g202323 graph, but in a graph metadata graph.
> Please lets proceed issue by issue and make
> sure every brick we place is really solid and separate this from
> visionary long term stuff.
Ok, I hope you see that I introduced nothing new there. It's just an
n3 notation that makes it easy to write things out in an e-mail.
So please consider that point again in that light.
>>
>> Then this API could use information from this graph to and information from
>> the user's request
>> to find the correct local graph he wants.
> Still the local graph would have a name, probably - but as I said its
> irrelevant. Lets deal with the issues at hand, you changed the names
> of graph (which I agree didn't have the best possible names) with
> names that I think are worse, lets find something we can agree upon.
> (otherwise, please roll back to the version with the orginal names
> till we find a consensus).
Well I don't think rolling back would improve anything. I think clearly
this was an improvement. But I do think we can do better.
So my thinking is that to reach consensus we can do this with an API, without
deciding what precisely the names should be. The best is just to lay out the
requirements:
1. mapping from a remote URI to the URI understood by the local triple store
and back. There should be no name clashes. It should be possible to easily extend
to have agent views and temporal views.
2. method for applications to take hold of legitimate namespaces in such a way that
a clash of names is not possible.
Henry
>
> Reto
>
>> Henry
>> PS. Having said that one then may just wonder why local graphs should ever
>> have anything other than
>> local URLs, since every time someone made a copy of a local graph it would
>> be different.
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
On Fri, May 13, 2011 at 5:46 PM, Henry Story <he...@bblfish.net> wrote:
> Clerrezza-489 and you also quote may statement of 463. okay, you might say
> that I'm stating rather than arguing.
>
> :-)
>
> The argument: they are different thing, both intensionally (cache and
> source) as in many case extensionally (triples may differ).
>
> in that sense I agree.
> But then the other point I made is also true, and that is that different
> users may get different
> graphs back for the same remote resource. In fact those users may be the
> same user at different times. Since those are all different graphs by your
> definition above one should also give them different names.
We do not have support for this yet and I think its a feature
increasing complexity massively. I don't think that clerezza-490 need
to be resolved urgently, but anyway we should proceed issue by issue,
and the best resolution of an issue is a minimal resolution not one
that tries to foresee and future issues.
> So local graph naming schemes should take that into account, which is why I
> suggest that we have an API that can allow for extensibility here.
We have currently things and we are naming them badly.
Prior to you r webproxy we had:
<webid-profile-url>.cache as name for the cache of the webprofile
and
<webid-profile-url> as uri for triples the user generated locally,
this can be seen as extensions to the remote profile with information
(like preferred language) that happen not to be in the remote profile
which was consistent with local users who only had
<webid-profile-url> for the triples they control which include both
the regular profile as well
Now <webid-profile-url> is the cache, not sure where additional
triples added locally get stored, i.e. where triples added to
webIdGraphsService.getWebIDInfo(webId).publicUserGraph are stored.
I'm not saying the old naming was perfect but it worked in a somehow
consistent fashion for local and remote users. Now my application taht
used this feature is now longer working.
> in Clerezza-489 I wrote that one could describe each graph like this in a
> special Cache graph perhaps.
> :g202323 a :Graph;
> = { ... };
> :fetchedFrom <https://remote.com/>;
> :fetchedBy <http://bblfish.net/people/henry/card#me>;
> :representation <file:/tmp/repr/202323>;
> :httpMeta [ etag "sdfsdfsddfs";
> validTo "2012...."^^xsd:dateTime;
> ... redirected info?
> ] .
>
> :g202324 a :Graph;
> = { ... };
> :fetchedFrom <https://remote.com/>;
> :fetchedBy <http://farewellutopia.com/reto#me>;
> :representation <file:/tmp/repr/202324>;
> :httpMeta [ etag "ddfsdfsddfd";
> validTo "2012...."^^xsd:dateTime;
> ... redirected info?
> ] .
If we had barketing in RDF and our tooling would support it the the
above might be somehow topical, answer to the question "how to name
this?" "don't name it". Please lets proceed issue by issue and make
sure every brick we place is really solid and separate this from
visionary long term stuff.
>
>
> Then this API could use information from this graph to and information from
> the user's request
> to find the correct local graph he wants.
Still the local graph would have a name, probably - but as I said its
irrelevant. Lets deal with the issues at hand, you changed the names
of graph (which I agree didn't have the best possible names) with
names that I think are worse, lets find something we can agree upon.
(otherwise, please roll back to the version with the orginal names
till we find a consensus).
Reto
> Henry
> PS. Having said that one then may just wonder why local graphs should ever
> have anything other than
> local URLs, since every time someone made a copy of a local graph it would
> be different.
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 13 May 2011, at 17:04, Reto Bachmann-Gmür wrote:
> ----- Original message -----
> >
> > On 13 May 2011, at 16:07, Reto Bachmann-Gmür wrote:
> >
> > > Well I did suggest an alternative in
> > > >
> > > >
>
> > > >
> > > > and in fact that is what the WebProxy implements - I think.
> > > >
> > > > And that is in short that remote graphs use the name of the remote
> > > > resource from which they come, and local graphs have local names.
> > >
> > > I argues why i strongly believe the local cache version must have a
> > > distint name than the remote graph. I agree the the original .cache
> > > suffix was not at all ideal, but i disagree with your change of just
> > > naming it by the uri of the remote graph.
> >
> > Sorry I must have missed that argument. Where do you argue that a local
> > cache version must have a distinct name?
>
> Clerrezza-489 and you also quote may statement of 463. okay, you might say that I'm stating rather than arguing.
>
:-)
> The argument: they are different thing, both intensionally (cache and source) as in many case extensionally (triples may differ).
>
in that sense I agree.
But then the other point I made is also true, and that is that different users may get different
graphs back for the same remote resource. In fact those users may be the same user at different times. Since those are all different graphs by your definition above one should also give them different names.
So local graph naming schemes should take that into account, which is why I suggest that we have an API that can allow for extensibility here.
in Clerezza-489 I wrote that one could describe each graph like this in a special Cache graph perhaps.
:g202323 a :Graph;
= { ... };
:fetchedFrom <https://remote.com/>;
:fetchedBy <http://bblfish.net/people/henry/card#me>;
:representation <file:/tmp/repr/202323>;
:httpMeta [ etag "sdfsdfsddfs";
validTo "2012...."^^xsd:dateTime;
... redirected info?
] .
:g202324 a :Graph;
= { ... };
:fetchedFrom <https://remote.com/>;
:fetchedBy <http://farewellutopia.com/reto#me>;
:representation <file:/tmp/repr/202324>;
:httpMeta [ etag "ddfsdfsddfd";
validTo "2012...."^^xsd:dateTime;
... redirected info?
] .
Then this API could use information from this graph to and information from the user's request
to find the correct local graph he wants.
Henry
PS. Having said that one then may just wonder why local graphs should ever have anything other than
local URLs, since every time someone made a copy of a local graph it would be different.
> Reto
> >
> > Henry
> >
> >
> >
> > Social Web Architect
> > http://bblfish.net/
> >
>
>
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Reto Bachmann-Gmür <re...@trialox.org>.
----- Original message -----
>
> On 13 May 2011, at 16:07, Reto Bachmann-Gmür wrote:
>
> > Well I did suggest an alternative in
> > >
> > > https://issues.apache.org/jira/browse/CLEREZZA-489
> > >
> > > and in fact that is what the WebProxy implements - I think.
> > >
> > > And that is in short that remote graphs use the name of the remote
> > > resource from which they come, and local graphs have local names.
> >
> > I argues why i strongly believe the local cache version must have a
> > distint name than the remote graph. I agree the the original .cache
> > suffix was not at all ideal, but i disagree with your change of just
> > naming it by the uri of the remote graph.
>
> Sorry I must have missed that argument. Where do you argue that a local
> cache version must have a distinct name?
Clerrezza-489 and you also quote may statement of 463. okay, you might say that I'm stating rather than arguing.
The argument: they are different thing, both intensionally (cache and source) as in many case extensionally (triples may differ).
Reto
>
> Henry
>
>
>
> Social Web Architect
> http://bblfish.net/
>
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 13 May 2011, at 16:07, Reto Bachmann-Gmür wrote:
> > Well I did suggest an alternative in
> >
> > https://issues.apache.org/jira/browse/CLEREZZA-489
> >
> > and in fact that is what the WebProxy implements - I think.
> >
> > And that is in short that remote graphs use the name of the remote
> > resource from which they come, and local graphs have local names.
>
> I argues why i strongly believe the local cache version must have a distint name than the remote graph. I agree the the original .cache suffix was not at all ideal, but i disagree with your change of just naming it by the uri of the remote graph.
Sorry I must have missed that argument. Where do you argue that a local cache version must have a distinct name?
Henry
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Reto Bachmann-Gmür <re...@trialox.org>.
----- Original message -----
>
> On 13 May 2011, at 14:45, Reto Bachmann-Gmuer wrote:
>
> > Use tha mialing lits for questions you encourage a broad discussiuon,
>
> well I don't see that there was much discussion here. People should feel
> free to join bug issue threads too. I'd rather that things don't get
> spread out everywhere - it's too easy to do that even in the issue
> database.
Okay, the issues there started containing very long term proposals foe new braketing mechanisms in rdf. My proposal was naming beyond graph. And is envisaged to have a short term way to clean up current inconsistencies.
>
> Well I did suggest an alternative in
>
> https://issues.apache.org/jira/browse/CLEREZZA-489
>
> and in fact that is what the WebProxy implements - I think.
>
> And that is in short that remote graphs use the name of the remote
> resource from which they come, and local graphs have local names.
I argues why i strongly believe the local cache version must have a distint name than the remote graph. I agree the the original .cache suffix was not at all ideal, but i disagree with your change of just naming it by the uri of the remote graph.
>
>
> >
> > Reto
> >
> >
> >
> > On Fri, May 13, 2011 at 2:37 PM, Henry Story <he...@bblfish.net>
> > wrote:
> > > Why are you having this debate on the mailing list? There are a
> > > number of bug reports where
> > > this issue has already been discussed?
> > > For example:
> > > https://issues.apache.org/jira/browse/CLEREZZA-489
> > > And there were a number of other bugs that are duplicates of it:
> > > CLEREZZA-470 and CLEREZZA-463.
> > > I just want to know when we are meant to use the mailing list and
> > > when the issue
> > > database.
> > >
> > >
> > >
> > > On 13 May 2011, at 13:36, Reto Bachmann-Gmür wrote:
> > >
> > > ----- Original message -----
> > > >
> > > > On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
> > > >
> > > > >
> > > > > For cached graphs I suggest to have uirs like:
> > > > >
> > > > > urn:x-localinstance:/cache/<remote-uri>
> > > >
> > > > -1
> > > >
> > > > Should each user who makes a request not get a different remote
> > > > graph?
> > >
> > > No, this would increase complexity too much. What is in the cache
> > > depens solely on the platform instance. If a user want to retrieve
> > > something with her identity she cannot use webproxy.
>
> If it increases complexity too much then why not just use the remote URI
> itself. Why add a meaningless piece of string in front of it? If
> simplicity is the criterion then just use the URI itself.
>
> When I mentioned that two users may need different graphs for the same
> remote URI that is in fact a criticisms of that simplest of ideas that
> I put forward. And I don't think it will be too complex to do. It is
> quite easy to imagine and describe in fact.
>
> In any case this has nothing to do with webproxy. This is an logical
> issue that will be had in any case. That is why it is worth thinking
> through a bit carefully, and why I welcome the discussion.
>
>
> > >
> > >
> > >
> > >
> > > > Because what if a remote instance returns different graphs to
> > > > different users for the same resource?
> > > >
> > > > Btw, I also opened this discussion in CLEREZZA-489 [1]
> > > >
> > > > My guess is that the graph management should hide all of this from
> > > > the user.
> > > >
> > > > The user should ask for relative graphs if he wants local ones.
> > > Which is a direct access to the cache graph, which is consitent with
> > > my proposal above.
>
> yes. So my proposal is that we distinguish the API from the local
> implementation.
>
> 1. We should allow the API to do the right thing: use relative URIs as
> much as possible. Use remote URIs for remote graphs. Be really
> simple. The developer should not have to bother with the arbitrary
> decisions of the implmentation below.
> 2. We should have a changeable implementation objects that do the
> transformation for the local setup. So if local quad store supports
> relative named graphs then it can use it. If it wants to choose my
> simple solution then ok use that. If it wants to chose a complex one
> then good.
>
> Such an object can even come with a transformer object, to help
> transform a database from one scheme to the other if the admin decides
> his initial idea was not that good.
>
>
> > >
> > > >
> > > > Then if he wants remote graphs he should use the name of the remote
> > > > graph he wishes to get. How that remote graph is named interally
> > > > is not really important.
> > > Which somehow contrasts your -1 above.
>
> Yes, I don't take a side initially in an argument. I try to see as
> many aspects of it as I can.
>
> > >
> > > > If the fetch is done over TCP without cookies or
> > > > headers, then presumably all users of the server can view that
> > > > graph equally. If fetching the remote graph requires
> > > > authentication, then the graph will be in part determined by who
> > > > fetched it.
> > > >
> > > > In the end these graphs should probably just be blank nodes, with
> > > > descriptors of how they were fetched.
> > > Yes, i a perfect world we have bracketing rdf stores so that graphs
> > > can be anonymously within others. But till then we need a key (name)
> > > for our named graph store.
> > >
> > > If you want to stick to your -1, could you popose an alternative?
> > >
> > > I really want to do some tidying in the proxy code.
>
> Well I don't quite get how
>
> urn:x-localinstance:/cache/<remote-uri>
>
> is any better than
>
> <remote-uri>
>
> the latter makes sense and is simple.
>
> Henry
>
>
> > >
> > > Cheers,
> > > reto
> > > >
> > > > Henry
> > > >
> > > > [1] https://issues.apache.org/jira/browse/
> > > >
> > > > Social Web Architect
> > > > http://bblfish.net/
> > > >
> > >
> > >
> > > Social Web Architect
> > > http://bblfish.net/
> > >
>
> Social Web Architect
> http://bblfish.net/
>
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 13 May 2011, at 14:45, Reto Bachmann-Gmuer wrote:
> Use tha mialing lits for questions you encourage a broad discussiuon,
well I don't see that there was much discussion here. People should feel free to
join bug issue threads too. I'd rather that things don't get spread out
everywhere - it's too easy to do that even in the issue database.
Anyway, you're still discussing with me here. So I don't see that this
makes much difference. Except that now we have to repeat the discussion
here.
> post a question-issue if you just would like to have an answer. I
> appreciate brain-storming issues, but here its about changes in the
> code. You're recent renaming of graphs caused some problems (e.g. my
> wall application no longer worked), so I wanted to try to get a
> consuns on the name to choose. Now I have you -1 but no alternative
> proposal.
Well I did suggest an alternative in
https://issues.apache.org/jira/browse/CLEREZZA-489
and in fact that is what the WebProxy implements - I think.
And that is in short that remote graphs use the name of the remote
resource from which they come, and local graphs have local names.
>
> Reto
>
>
>
> On Fri, May 13, 2011 at 2:37 PM, Henry Story <he...@bblfish.net> wrote:
>> Why are you having this debate on the mailing list? There are a number of
>> bug reports where
>> this issue has already been discussed?
>> For example:
>> https://issues.apache.org/jira/browse/CLEREZZA-489
>> And there were a number of other bugs that are duplicates of it:
>> CLEREZZA-470 and CLEREZZA-463.
>> I just want to know when we are meant to use the mailing list and when the
>> issue
>> database.
>>
>>
>>
>> On 13 May 2011, at 13:36, Reto Bachmann-Gmür wrote:
>>
>> ----- Original message -----
>>>
>>> On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
>>>
>>>>
>>>> For cached graphs I suggest to have uirs like:
>>>>
>>>> urn:x-localinstance:/cache/<remote-uri>
>>>
>>> -1
>>>
>>> Should each user who makes a request not get a different remote graph?
>>
>> No, this would increase complexity too much. What is in the cache depens
>> solely on the platform instance. If a user want to retrieve something with
>> her identity she cannot use webproxy.
If it increases complexity too much then why not just use the remote URI itself.
Why add a meaningless piece of string in front of it? If simplicity is the criterion
then just use the URI itself.
When I mentioned that two users may need different graphs for the same remote URI
that is in fact a criticisms of that simplest of ideas that I put forward. And
I don't think it will be too complex to do. It is quite easy to imagine and describe
in fact.
In any case this has nothing to do with webproxy. This is an logical issue that will be
had in any case. That is why it is worth thinking through a bit carefully, and why I
welcome the discussion.
>>
>>
>>
>>
>>> Because what if a remote instance returns different graphs to different
>>> users for the same resource?
>>>
>>> Btw, I also opened this discussion in CLEREZZA-489 [1]
>>>
>>> My guess is that the graph management should hide all of this from the
>>> user.
>>>
>>> The user should ask for relative graphs if he wants local ones.
>> Which is a direct access to the cache graph, which is consitent with my
>> proposal above.
yes. So my proposal is that we distinguish the API from the local implementation.
1. We should allow the API to do the right thing: use relative URIs as much
as possible. Use remote URIs for remote graphs. Be really simple. The developer
should not have to bother with the arbitrary decisions of the implmentation below.
2. We should have a changeable implementation objects that do the transformation for
the local setup. So if local quad store supports relative named graphs then it can use
it. If it wants to choose my simple solution then ok use that. If it wants to chose a complex
one then good.
Such an object can even come with a transformer object, to help transform a database
from one scheme to the other if the admin decides his initial idea was not that good.
>>
>>>
>>> Then if he wants remote graphs he should use the name of the remote
>>> graph he wishes to get. How that remote graph is named interally is not
>>> really important.
>> Which somehow contrasts your -1 above.
Yes, I don't take a side initially in an argument. I try to see as many aspects
of it as I can.
>>
>>> If the fetch is done over TCP without cookies or
>>> headers, then presumably all users of the server can view that graph
>>> equally. If fetching the remote graph requires authentication, then the
>>> graph will be in part determined by who fetched it.
>>>
>>> In the end these graphs should probably just be blank nodes, with
>>> descriptors of how they were fetched.
>> Yes, i a perfect world we have bracketing rdf stores so that graphs can be
>> anonymously within others. But till then we need a key (name) for our named
>> graph store.
>>
>> If you want to stick to your -1, could you popose an alternative?
>>
>> I really want to do some tidying in the proxy code.
Well I don't quite get how
urn:x-localinstance:/cache/<remote-uri>
is any better than
<remote-uri>
the latter makes sense and is simple.
Henry
>>
>> Cheers,
>> reto
>>>
>>> Henry
>>>
>>> [1] https://issues.apache.org/jira/browse/
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
Use tha mialing lits for questions you encourage a broad discussiuon,
post a question-issue if you just would like to have an answer. I
appreciate brain-storming issues, but here its about changes in the
code. You're recent renaming of graphs caused some problems (e.g. my
wall application no longer worked), so I wanted to try to get a
consuns on the name to choose. Now I have you -1 but no alternative
proposal.
Reto
On Fri, May 13, 2011 at 2:37 PM, Henry Story <he...@bblfish.net> wrote:
> Why are you having this debate on the mailing list? There are a number of
> bug reports where
> this issue has already been discussed?
> For example:
> https://issues.apache.org/jira/browse/CLEREZZA-489
> And there were a number of other bugs that are duplicates of it:
> CLEREZZA-470 and CLEREZZA-463.
> I just want to know when we are meant to use the mailing list and when the
> issue
> database.
>
>
>
> On 13 May 2011, at 13:36, Reto Bachmann-Gmür wrote:
>
> ----- Original message -----
>>
>> On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
>>
>> >
>> > For cached graphs I suggest to have uirs like:
>> >
>> > urn:x-localinstance:/cache/<remote-uri>
>>
>> -1
>>
>> Should each user who makes a request not get a different remote graph?
>
> No, this would increase complexity too much. What is in the cache depens
> solely on the platform instance. If a user want to retrieve something with
> her identity she cannot use webproxy.
>
>
>
>
>> Because what if a remote instance returns different graphs to different
>> users for the same resource?
>>
>> Btw, I also opened this discussion in CLEREZZA-489 [1]
>>
>> My guess is that the graph management should hide all of this from the
>> user.
>>
>> The user should ask for relative graphs if he wants local ones.
> Which is a direct access to the cache graph, which is consitent with my
> proposal above.
>
>>
>> Then if he wants remote graphs he should use the name of the remote
>> graph he wishes to get. How that remote graph is named interally is not
>> really important.
> Which somehow contrasts your -1 above.
>
>> If the fetch is done over TCP without cookies or
>> headers, then presumably all users of the server can view that graph
>> equally. If fetching the remote graph requires authentication, then the
>> graph will be in part determined by who fetched it.
>>
>> In the end these graphs should probably just be blank nodes, with
>> descriptors of how they were fetched.
> Yes, i a perfect world we have bracketing rdf stores so that graphs can be
> anonymously within others. But till then we need a key (name) for our named
> graph store.
>
> If you want to stick to your -1, could you popose an alternative?
>
> I really want to do some tidying in the proxy code.
>
> Cheers,
> reto
>>
>> Henry
>>
>> [1] https://issues.apache.org/jira/browse/
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>
>
> Social Web Architect
> http://bblfish.net/
>
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
Why are you having this debate on the mailing list? There are a number of bug reports where
this issue has already been discussed?
For example:
https://issues.apache.org/jira/browse/CLEREZZA-489
And there were a number of other bugs that are duplicates of it:
CLEREZZA-470 and CLEREZZA-463.
I just want to know when we are meant to use the mailing list and when the issue
database.
On 13 May 2011, at 13:36, Reto Bachmann-Gmür wrote:
> ----- Original message -----
> >
> > On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
> >
> > >
> > > For cached graphs I suggest to have uirs like:
> > >
> > > urn:x-localinstance:/cache/<remote-uri>
> >
> > -1
> >
> > Should each user who makes a request not get a different remote graph?
>
> No, this would increase complexity too much. What is in the cache depens solely on the platform instance. If a user want to retrieve something with her identity she cannot use webproxy.
>
>
> > Because what if a remote instance returns different graphs to different
> > users for the same resource?
> >
> > Btw, I also opened this discussion in CLEREZZA-489 [1]
> >
> > My guess is that the graph management should hide all of this from the
> > user.
> >
> > The user should ask for relative graphs if he wants local ones.
> Which is a direct access to the cache graph, which is consitent with my proposal above.
>
> >
> > Then if he wants remote graphs he should use the name of the remote
> > graph he wishes to get. How that remote graph is named interally is not
> > really important.
> Which somehow contrasts your -1 above.
>
> > If the fetch is done over TCP without cookies or
> > headers, then presumably all users of the server can view that graph
> > equally. If fetching the remote graph requires authentication, then the
> > graph will be in part determined by who fetched it.
> >
> > In the end these graphs should probably just be blank nodes, with
> > descriptors of how they were fetched.
> Yes, i a perfect world we have bracketing rdf stores so that graphs can be anonymously within others. But till then we need a key (name) for our named graph store.
>
> If you want to stick to your -1, could you popose an alternative?
>
> I really want to do some tidying in the proxy code.
>
> Cheers,
> reto
> >
> > Henry
> >
> > [1] https://issues.apache.org/jira/browse/
> >
> > Social Web Architect
> > http://bblfish.net/
> >
>
>
Social Web Architect
http://bblfish.net/
Re: How to name things with URIs
Posted by Reto Bachmann-Gmür <re...@trialox.org>.
----- Original message -----
>
> On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
>
> >
> > For cached graphs I suggest to have uirs like:
> >
> > urn:x-localinstance:/cache/<remote-uri>
>
> -1
>
> Should each user who makes a request not get a different remote graph?
No, this would increase complexity too much. What is in the cache depens solely on the platform instance. If a user want to retrieve something with her identity she cannot use webproxy.
> Because what if a remote instance returns different graphs to different
> users for the same resource?
>
> Btw, I also opened this discussion in CLEREZZA-489 [1]
>
> My guess is that the graph management should hide all of this from the
> user.
>
> The user should ask for relative graphs if he wants local ones.
Which is a direct access to the cache graph, which is consitent with my proposal above.
>
> Then if he wants remote graphs he should use the name of the remote
> graph he wishes to get. How that remote graph is named interally is not
> really important.
Which somehow contrasts your -1 above.
> If the fetch is done over TCP without cookies or
> headers, then presumably all users of the server can view that graph
> equally. If fetching the remote graph requires authentication, then the
> graph will be in part determined by who fetched it.
>
> In the end these graphs should probably just be blank nodes, with
> descriptors of how they were fetched.
Yes, i a perfect world we have bracketing rdf stores so that graphs can be anonymously within others. But till then we need a key (name) for our named graph store.
If you want to stick to your -1, could you popose an alternative?
I really want to do some tidying in the proxy code.
Cheers,
reto
>
> Henry
>
> [1] https://issues.apache.org/jira/browse/
>
> Social Web Architect
> http://bblfish.net/
>
Re: How to name things with URIs
Posted by Henry Story <he...@bblfish.net>.
On 10 May 2011, at 14:44, Reto Bachmann-Gmuer wrote:
>
> For cached graphs I suggest to have uirs like:
>
> urn:x-localinstance:/cache/<remote-uri>
-1
Should each user who makes a request not get a different remote graph?
Because what if a remote instance returns different graphs to different users for the same resource?
Btw, I also opened this discussion in CLEREZZA-489 [1]
My guess is that the graph management should hide all of this from the user.
The user should ask for relative graphs if he wants local ones.
Then if he wants remote graphs he should use the name of the remote graph he wishes to get. How that remote graph is named interally is not really important. If the fetch is done over TCP without cookies or headers, then presumably all users of the server can view that graph equally. If fetching the remote graph requires authentication, then the graph will be in part determined by who fetched it.
In the end these graphs should probably just be blank nodes, with descriptors of how they were fetched.
Henry
[1] https://issues.apache.org/jira/browse/
Social Web Architect
http://bblfish.net/