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