So I am considering in detail Reto's explanation of the family of 540 patches.
On 6 Jun 2011, at 16:03, Reto Bachmann-Gmuer wrote:
> - What problem does CLEREZZA-544 address?
>
> Without the proposed patches for 540 and its dependencies the discobits
> typehandler returns the requested resource as GraphNode from the
> content-graph.
(The Discobit type handler is what 541 touches, which I had not looked at yet.)
It seems to still return a GraphNode. But now it delegates to the
GraphNodeProvider to get it. So with the patch and without the patch it returns
a GraphNode...
> This resource may have properties pointing to other resources.
> When one accesses that resource as RDF it gets the MSG with
> recursively the MSG of resources that only differ in their names by a
> fragment identifier added to the name of the graph-node resource.
Before the changes it
1. fetched the content graph
2. checked that the named resource's "graph context" is not empty
Or more clearly: we are in JSR311 code, in a @GET annotated method, and it
checks that something is said about that web page in the content graph.
3. Then it takes the graph of all local "web-pages" as named in the content
graph, and creates a name mapper ( UriMutatingTripleCollection ) that maps
those names to the internal naming system (or vice versa)
[ so this is the issue with graph names we discussed on the thread a month
ago in length I suppose ]
4. it returns the graph of these hostnames and the content graph.
Afterwards:
it returns the graph returned by the GraphNodeProvider which contains the
UriMutatingTripleCollection
logic.
I am not sure the difference between the old and the new code lies here at all.
This looks more at this point like a refactoring.
> As a
> consequence of this the expansion of the resource by a renderlet may or may
> not be based on the same triples that one would get when dereferencing the
> linked resource, this is true in the general case for local resources but
> much more for remote resources in which case the renderlet has only access
> to the triples in the graph underlying the main resource and not the
> description one can get over the web. Currently one has to implement a root
> resource or a typehandler and add the information of the referenced resource
> to the graph underlying the graphnode. This is ugly as the added triples are
> not scoped to the remote resource.
The above is really difficult to understand. But as I understand there is the
need in this case to have the content graph union any remote graphs.
>
> Example: At local uri <xy> the user should get a list of articles from the
> content graph, every article should have a box with information about the
> author. This information should be retrieved from the foaf-profiles of the
> authors.
ok, good example.
(So in the case of the account control panel I am working on we may want to
display a box
of information about each friend...)
>
> Current bad solution: We make a typehandler or root resource that generated
> the response for <xy> and we return a graphnode with as underlying graph the
> union of the content graph and the profile graph of every author. In the
> renderlet (or ssp) we call render passing the GraphNode returned by
> article/foaf:maker as argument.
>
> Solution using the proposed patches: Making a typehandler or root resource
> is not needed. In the renderlet (or ssp) we call render passing the UriRef
> returned by article/foaf:maker! as argument.
ok. And then you get back at each iteration a graph containing the content graph
union the graph of the user. Those will be different union graphs at each go,
and
there may be the type of clashes I described previously: with for example
locally
stored telephone/address/... unioned with the remote telephone/address etc..
This is useful sometimes, but one has to be aware of the interplay of local and
remote information. In my use cases this is sometimes something one wants to
avoid.
>
> - What's bad with the current solution?
>
> The remote profiles may contain triples about any resource, so the profile
> could also contain infromation about other information displayed on the same
> page, e.g. about other authors.
yes, so because you have a larger union there is more of a risk of a clash. By
reducing the union one can reduce the clash. (Or is there some other reason
here?)
In my applications I was interested in just having the remote profile - ie, no
union at all - because you want to friend someone and see what they say about
themselves before deciding. (though one would also like to know what other
people one knows say about them too - and possible who says what: so unions
won't be that useful, unless they can easily be broken up again)
> - What's the alternative solution Henry proposes?
>
> At one time there was a package webproxy in the Clerezza trunk. This was a
> service accessible from Renderlets and ScalaServerPages allowing to
> dereference (or get cached copies) of remote graphs. Using this a renderlet
> could get a remote graph, locate the resource in it and create a new
> graphnode that could the be passed to the render method. The WebProxy
> service was a major new API introducing a whole bunch of new public methods
> and a new class for describing resources.
Look it did its job. I never said it was final or fit in with everything else
in ZZ. Nor can I know ahead of time how it fits best into what ZZ does. Your
refactoring
here suggests that you yourself don't know ahead of time what is best. Why was
the motto:
if you don't like it don't use it NOT applicable there? Why not just enter a
new issue to
refactor it to something better? Then at least you would have allowed me to
close an issue,
and acknowledge my contribution, and then we could discuss the pros and cons
of new ways
of doing things. ANYWAY...
> This new service did not integrate
> with TcManager and was using platform services despite being an SCB-bundle.
> The Bundle was removed after having been in large parts obsoleted by
> rdf.storage.web and after creating problems with a graph-renaming it
> introduced.
? Ah the problem of graph renaming it "introduced" was an improvement over an
existing graph renaming problem you yourself have acknowledged and which I told
you about when I helped you add WebID to Clerezza last summer. Naming remote
resources by appending ".cache" was clearly not good. It fixed that problem,
but you thought you could do better. Ok, but why not acknowledge that I
introduced a fix, rather than putting it in terms of me introducing a bug.
There followed then a discussion on graph naming, where you put forward another
fix to the ".cache" problem. There was a discussion there too, but let's get
along with life...
I did find that very useful in my use case to be able to work without having
the content graph appended to the remote graph. In your use case that may be
different, but if you remove my option and force me to use yours then don't
then argue that I don't need to use your code!!!!!
In any case THAT IS NOT THE ALTERNATIVE SOLUTION I PROPOSED recently on this
thread.
Wwhat I am proposing is the creation of more flexible GraphNodes which can have
for different
applications different logics for dereferencing remote graphs if needed. So
instead of your DiscobitsTypeHandler requiring a graphNodeProvider to fetch the
remote graphs it could return
a new DBContentGraphNode(uri), and that information could be then filled in
before reaching the renderlet.
Renderlets could then also create different types of GraphNodes, for example a
RemoteGraphNode(uri) for my use case, and a ContentGraphNode(uri) for your use
case, and others for yet other use cases. (eg, one that finds just what MY
friends think about someone) They would be easy to create, and we could all try
out different methods of filling this out.
I am not 100% sure of this of course, but as a first suggestion something like
that looks like it could help us both, and perhaps even make code a lot more
readable.
>
> [...]
>
>>
>> The problem with this is that the trust decisions made by the
>> GraphNodeProvider are now hidden in the very
>> complex decision procedure to be found in its code, which depends on yet
>> other Providers which themselves are
>> not clear. These functions will be hidden to the programmer returning a
>> UriRef from the JSR311 code.
>>
>> The point of the compromise solution is rather to help make these decisions
>> transparently clear. It would be much better to create declaratively typed
>> GraphNode objects with different and clearly defined behaviours. But here
>> the whole rendering engine is pushed to make a pretty arbitrary choice on
>> what is to be trusted. This does not need to be the case.
>> We can do better.
>>
>> In any case I don't remember reading a good defence of why suddenly these
>> changes are needed.
>>
>
> It seems you're not reading my replies very carefully. Despite me correcting
> you twice you're still talking about JSR311 returning UriRefs, for the whole
> renderlet/ssp mechanism to be used a JaxRs (aka jsr311) resource method
> returns a GraphNode.
Ok, so you are having SSP code call do rendering on URIs.
> With pre-540 DiscobitsTypeHandler this was only based
> on the content-graph. You're opposing to this patch which also adds the
> remote graph for remote resources but you don't specify what the underlying
> graph should be.
I am just saying that there are many cases here, and we can be flexible about
how this works out.
>
> Reto
>
>
>
>>
>> Henry
>>
>>
>>>
>>>
>>>
>>>>
>>>> I don't think that the patch henry vetoed has anything bad in it, or
>> brings
>>>> something one has to compensate for. If the platform is asked "tell me
>>>> about
>>>> xy" it tells what the platform takes for reasoanbly granted, that is by
>>>> default what it get from an authoritative description on the weeb and
>> from
>>>> the public part of its own trusted data.
>>>>
>>>
>>> right, I agree with you and I am still +1 to the proposed patch, sorry if
>> I
>>> wasn't clear enough.
>>> Tommaso
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
Social Web Architect
http://bblfish.net/
