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 <[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/
