----- 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 <[email protected]> > > 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/ >
