On Sun, May 15, 2011 at 11:28 AM, Henry Story <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>>> 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 <[email protected]> >>>>>> 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/ > >
