incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <henry.st...@bblfish.net>
Subject Re: How to name things with URIs
Date Sat, 14 May 2011 22:45:06 GMT

On 14 May 2011, at 22:37, Reto Bachmann-Gmuer wrote:

> On Sat, May 14, 2011 at 7:54 PM, Henry Story <henry.story@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 <henry.story@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/&gt;;
>>>>     :fetchedBy <http://bblfish.net/people/henry/card#me&gt;;
>>>>     :representation <file:/tmp/repr/202323>;
>>>>     :httpMeta [ etag "sdfsdfsddfs";
>>>>                      validTo "2012...."^^xsd:dateTime;
>>>>                     ... redirected info?
>>>>                     ] .
>>>> 
>>>> :g202324 a :Graph;
>>>>     = { ... };
>>>>     :fetchedFrom <https://remote.com/&gt;;
>>>>     :fetchedBy <http://farewellutopia.com/reto#me&gt;;
>>>>     :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/


Mime
View raw message