Hello guys, I am ok to give the GraphNodeProviderService a wider scope than a platform-only service but I don't think every JSR311 class has to use it, so for example if one wants to implement a service which is more restrictive well, then one can simply not use it, no? It seems to me this's also the spirit of Henry's compromise solution. Maybe I am just making it too simple, so please correct me if I am wrong here. My opinion is that also CLEREZZA-544 corrects a previous issue with the context used, the plan could be to add an optional Filter to restrict what remains exposed in the context. My 2 cents, Tommaso
2011/6/3 Reto Bachmann-Gmuer <[email protected]> > On Wed, Jun 1, 2011 at 7:05 PM, Henry Story <[email protected]> > wrote: > [...] > > > > Yes, TcManager is the main entry point to the rdf data. I don't see any > > code > > > smell here. I a classical RDBMS java application a component will > > typically > > > use jdbc and rely on other components that use jdbc, here it's > TcManager > > > instead of jdbc, > > > > The thing to do would be to look at the number of connections that are > > generated to the > > DB. My feeling is that one could do the same and have only 1 or 2 > > connections to the DB. > > Here we could quickly end up with 10 times more.... > > > I don't know what you mean by DB conncetions and where you see this factor > 10. > > [...] > > > > > > >> On my fresh install of ZZ that is 20 times more information than the > > >> initial graph. > > >> > > > - What is 20 times more? > > > - What do you mean by "get"? > > > > > > A graphnode point to a resource and is designed for browsing from > > resource > > > to resource. It is not a graph but a node in a graph. The object is > > > associated to a base-graph which used to identify the propertied and > > > instanctiate another graphnode when hoping to a property value. The > > > underlying graph could for instance be Timbl's GGG (giant gloabl graph > > aka > > > the web). > > > > yes ((but clearly you don't want to dereference the whole web when > > working...)) > > > no, and nobody is doing this. If I include the uri pattern > <http(s)://.*/(.*/)*> I'm not blasting this mail to the size of the web. > > > > > > Also there will be contradictions in the information on the web. Some > > people may trust some graphs, other trust others. > > Right, that's why the GraphNodeProvider trusts only the content-graph, > which > is trusted qua being a platform service) and the graph resulting from > dereferencing the resource (trusted by conventional web-trust) > > > > Graphs can be merged easily in RDF - IF they are believed both to be > true. > > But what is believed to be true will depend on what possible world you > > believe yourself to be in. I argued this in "Beatnik: change your mind" > > in more detail, if that helps for people following this discussion > > > > http://blogs.oracle.com/bblfish/entry/beatnik_change_your_mind > > > > From the point of view of WebID and security I want to be able to tell > WHO > > said what. In many applications being able to be very clear about where > > something was said is going to be essential to giving good feedback. > Some > > example coming from the field I am working on below. > > > > > So for a foaf-browser, I want to know when TimBl declares someone to be a > > friend, and differentiate that from when someone declares himself to be a > > friend of TimBL, which is a very different thing. > > With the current service you have what TimBL says plus the platform-wide > truths of the content-graph, this may contain things like a link back to > you > (the owner of the platform instance) or a statement like : TimBL rdf:type > ex: Spammer which might not be published in TimBL's profile > > > > When I get Dan Brickley's graph I may want to know all the people he > > mentions in his foaf profile - even if he does not mention them as > > foaf:knows related to him. > > does this provide a new point? > > > > If the GraphNodeProvider returns a union graph of the documentation > graph, > > Again no, we're not returning a union graph we're returning a GraphNode, > the > underlying graph is an implementation detail (was think if the > getGraph-method could be made less visible (protected or private) to avoid > this confusion) > > > > content graph,... and his foaf profile then when searching for all the > > foaf:Person > > You don't search a GraphNode for all foaf:Person but the GraphNode > represents the foaf:Person you asked for. > > > > I will get the documentation writers too, the writers of content in the > > content graph, and who knows what else... > > you will have properties pointing from that persons to all the comments he > left on the local instance, which can be quite handy (and which are from > the > underlying content graph as they are probably not also contained in the > remote foaf:profile) > > > > many people will have no direct relation to Dan at all. People can say > true > > things about Dan but those not be things Dan himself would say. > > > Yes, we only consider as true what we say ourseflf (i.e. the content graph) > and in particular circumstances also what Dan says. > > > > > > I believe these use cases are not limited to the foaf browser but to a > very > > large category of semantic web applications. Give me some linked data > > application, and I will easily come up with use cases of the same kind. > > > That's why graphnodeprovider is a generic service and its not true that it > was designed for a particular and very specific application of mines in > mind. > [...] > > > > > > > I thought I had heard people mention issues with speed on this list. > > >> > > > You may check archives of this list at: > > > http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/ > > > > Do you have a precise thread? > > > No, its you who thought he heard people mention issue with speed. Check the > archive and construct an argument if those speed issues relate to the issue > at hand, otherwise your remark " I thought I had heard people mention > issues > with speed on this list" is purely demagogic and a hindrance to an > effective > an fruitful discussion. (like saying "I've heard people finding the > clerezza > code hard to read" when justifying a -1 against some code) > > > [...] > > >> > > >> What I am wondering is in what cases is this needed? It seems like > this > > may > > >> indeed what a particular application may require, but does it have to > be > > >> a general service? The name certainly suggests a very general service, > > not > > >> one required for a particular application. > > >> > > > This is about ContentGraphProvider then, not about issue 540. It's the > > > ContentGraphProvider which provides the graph of instance-wide and > public > > > information for the platform > > > > 540 the GraphNodeProvider delegates decisions to the ContentGraphProvider > > 544 uses the GraphNodeProvider that delegates to the ContentGraphProvider > > and ties it into the the core, > > so that when a JSR311 class requests a named graph it then gets > whatever > > the ContentGraphProvider decides > > is trusted content. > > > I don't see any link to JSR311 but yes, the ContentGraphProvider provides > content that is public and platform-wide trusted by default (the system > graph has higher trust). > > > > > > SKETCH OF A COMPROMISE SOLUTION > > =============================== > > > > Perhaps there is a way to allow make things more transparent, by for > > example having JSR311 classes that really > > want the full union returned by the current ContentGraphProvider to have > > that, and other applications to get something more limited. > > > Again see no link to Jsr311. But I think this might be the mentioned > possible future enhancement to allow clients to specify the trust > boundaries. > > > > I suggest that we think of naming the content graph or at least build > > something so that those who need the content graph can ask for it > clearly, > > and those who don't can make sure they don't get it. > > > The content graph is named, the virtual content graph isn't, but we could > give the virtaul content graph a name thus making it accessible in sparql > queries (using a TcProvider) but this seems completely unrelated to the > issue at hand. > > > > > > - It may be useful then to name the content graph - it would be a union > > graph that could be specified by a SPARQL UNION > > query for example or the equivalent. > > > Yes, if we give the Virtual content graph it can be used by the sparql > endpoint > > > > > > - have a JSR311 class return a NamedGraphNode (or something like that) > > which can then call the CallbackRenderer. > > > What should a NamedGraphNode be? GarphNode can wrap a named or an anonymous > resource I see no need for a subclass for UriRef-GraphNodes, but we have > been discussing this in another thread, don't see a relation to the issue > at > hand. > > I don't know what you mean by the NamedGraphNode calling CallbackRenderer, > the CallbackRenderer is called by the renderlet. > > The NamedGraphNode could name the union graph, or could be a union graph > > - by reference. So all the code would do is > > > > return new UnionNamedGraphNode(new > > UriRef("urn:x-localhost/contentGraph"),new UriRef(" > > http://remote.example/resource/";)) > > > > I'm not getting it which one is the resource and which one the name of the > underlying graph, whats the difference to current GraphNodes. > > > > > > or some nice syntactic sugar for that. For example for apps requiring > > the union of Content + other that you need, something like the > following > > would be neat > > > > return new ContentGraphNodePlus(UriRef(" > http://remote.example/resource/ > > ")) > > > > If you're talking about GraphNodes (but I'm not sure where you in fact mean > graphs) the I don't see what you're introducing that is new > > return new GraphNode(new UriRef("http://remote.example/resource/";), new > UnionMGraph(contentGraph, fooGraph, barGraph)) > > > > > > These objects would just be holders of the graph name(s), which the > > TcManagers can then hook up into the underlying triple store. Something > > along those lines would be very nice. One could easily write applications > > that get union of contents as you wish, and I could easily get very > > precisely defined graphs for security based application, or more flexible > > linked data graphs too. > > You can do this (see example return statement above) > > > > It could also avoid the iterative way the GraphNodeProvider currently > > works. > > > Is this a reference to the if-then statements you criticed but never told > me > what you mean despite me repatedly asking? Or what "iterative way" are you > reffering to? > > > > > > Having something like that would mean that perhaps the addition of the > > new method in CallbackRenderer > > > > public void render(UriRef resource, GraphNode context, String mode, > > OutputStream os) throws IOException; > > > GarphNode is resource+context where the context is a graph. Now the > renderlet gets a graphnode to render, it shouldn't get any context from > anywhere else. the new render method is exactly to render a method with a > differnt context not avaialble directly to the renderlet. If the outer > renderlet already has (or can generate) the context for the nested > rendering > the this can be done with existing (pre 540) infrastructure. > > > > > > > > would no longer be needed, or would be adapted somewhat. > > what? > > > > It could also mean that the GraphNodeProvider could be a lot more > general, > > as its name indicates it should be. The information about graphs hard > coded > > into the provider could then be moved to a Graph (or GraphNode or > NamedGraph > > or NamedGraphNode object). It would then be a lot clearer when looking at > > JSR311 code what was being returned. > > > Again this is not specific to jsr311 code. I think my proposed > GraphNodeProvider is quite generic but that additional features coould be > added. > > > > > > [[ ps: a thought > > One could perhpas write implementations of such a NamedGraph that would > > perhaps allow links to be followed outward (from accepted named graphs to > > others graphs it links to, up to a certain number of hops). > > ]] > > > Which seems to be exactly the context-switch allowed by ZZ-544 > > > > > > >> Perhaps changing the name from GraphNodeProvider to > > >> ContentGraphPlusOtherProvider would make more sense. > > > It's a platform service that provides GraphNodes. Being a platform > > service > > > implies it usesthe platform means of getting trusted content. If it > would > > > just dereference URIs the it would probably be placed in a subpackage > of > > > clerezza.rdf. > > > > perhaps. But why not make things nice and general as explained above? > > > Where do you make something nice and more general? You're describing how > clients can do stuff without GraphNodeProvider what they of course can do. > And you're proposing new classes for what seems they can do as easily (but > more consistently and thus more elegantly) with the existing classes. > > > > > Currently with changes to 544 and in particular the render method > > > > public void render(UriRef resource, GraphNode context, String mode, > > OutputStream os) throws IOException; > > > > > > when a JSR311 class returns a URI, > > A jsr311 returns a GraphNode, if it returns a URI then type-rendering is > not > used (but another MessageBodyWriter, if available) > > > > the renderer does not get the graph named by that > > URI > > No renderlets get invoked, but if it gets a graphNode the renderlets gets > that GraphNode which allows ecploring the resource with whatever graph the > jax-rs resource method chose to use. Choosing this graph is the business of > the application logic and certainly does not belong into the renderlet. > > > > but that graph and something else, defined in some unrelated package. For > > me this > > does not make it easy to understand the code. > > > Obviously you don't. Would be good we find way to improve understanding of > the clerezza architecture without requiring blocking the evolution by > casting -1 > > > > > > > > >>> This might not match an intuitive understanding of "authoritative" > and > > >> I'm > > >>> happy to redefine the issue so that no confusion arises. > > >> > > >> One thing I am not quite clear about yet, is who writes to the content > > >> graph? I see a lot of modules use it. > > >> > > > Modules can write to the content graph or add temporary additions to > it. > > > Actually writing to the content graph should happen when public and > > trusted > > > information is added. An information is considered trusted when added > by > > a > > > user with respective permission or verified by privileged code (e.g. > that > > > allows the public to add see-also references). > > > > Good so say a trusted user of mine :joe truthfully says > > > Waht do you mean by "trusted user"? trust with no limits? (admin rights?) > > > > > > > b:danbri foaf:knows :joe . > > > > then currently when I ask for http://danbri.org/foaf.rdf#danbri > > I will get a graph that contains the above triple even if danbri does not > > make that > > claim. Sometimes that is good, and sometimes not. > > Sometimes it's good to use clerezza, sometimes a hammer is more appropriate > ;) > > > > In many cases as I have argued it will be > > important for me to know what danbri claims. Perhaps so I can ping him to > > tell him about > > my desire for him to claim friendship with me. > > > There's nothing to prevent you or that would make it hard to write such an > application, it's just not what the garphnodeprovider is for and it > definitively doesn't belong into the renderlet > > > > > > In the current API changes it won't be clear at all why when I ask for > > > > <http://danbri.org/foaf.rdf#danbri> > > > > I get <http://danbri.org/foaf.rdf#danbri> + 5 other graphs. > > graph/resource distinction, what does the addition of a person and a graph > result in? > > > > Or it will require the developer > > to know the internals of clerezza to work this out, as I have just had to > > do myself. > > > It can well be, that clerezza will support sophisticated provenance > mechanism in future. Not sure however if the blocking of patches for the > existing base architecture fosters this developement. > > [...] > > > > > > > > >> 4. But instead of just having a GraphNodeProvider that just returns > the > > >> graph, you have added some twists to > > >> it and return more than jut the named graph. There is nothing to say > > that > > >> a named graph cannot be the union > > >> of many other graphs, but it seems really arbitrary for me to get the > > >> documentation of clerezza along with the > > >> triples of Tim Berners Lee's graph. > > >> > > > > > >> Somehow things have gone a bit haywire at the end here. > > > > > > If you call getGraph on a GraphNode you're leaving the scope of the > > > GraphNode. Probably all this discussion would not be necessary if had > > been > > > using getNodeContext instead of getGraph. The NodeContext is what > related > > to > > > the node. Using getGraph is a bit like doing the following: > > > > > > File file = SomeService.getFileDescribing("Tim Berners Lee") > > > file.getParent().getParent().getParent().listChildrenRecursively() > > > > I don't think that is a good way of looking at what graphs are useful > for. > > Graphs are more > > like bubbles in a comic strip. > > > Yes, but here it's not about graph but resources (interpreted in a huge > universe of believes) > > > > > > I argue this very carefully in "Are OO languages Autistic?" > > > > http://blogs.oracle.com/bblfish/entry/are_oo_languages_autistic > > > > This is a fundamental new programming element provided in the semantic > web. > > > > So the context as you are defining it is not what I am looking for. I am > > really looking for the named graph - the entire claim made by a resource. > > We don't have the notion of claims made by a resource. But it would be easy > to add a methos to GraphNodeProvider returning only what the web offers as > context of a resource > > > > This can be seen by considering the example I gave above where someone > adds > > to the content graph information about Dan Brickley > > > > b:danbri foaf:knows :joe . > > > > If I only get Dan Brickely's graph back that triple will not be there. If > I > > get Dan Brickley's + the content graph, then that information will > appear > > even if I just ask for dan's node context. Also there may be information > > about > > people appearing in Dan Brickley's profile that are not directly linked > by > > him, that I will > > also be interested in retrieving. > > > Use render(uriRef) method to have thos people rendered in their context. > > > > So the context is not the tool I need - and I don't think my use cases > are > > special. > > > In the usecase of telling Dan that a true statement is missing indeed what > id provided by ZZ-540 is probably not what you need. But I think this > usecase is more special than seein all the comments a person posted and > other facts which are assumed to be true (by platform trust boundaries) > about a person. But this discussion is pointless as one feature doesn't > prevent the other from being implemented. > > > > > > > > > > The listed files can contain thigs that are completely unrelated to Tim > > > Berners Lee > > > > > > > > > > > >> And I think this is due to a bit of confusion of the needs > > >> of your application with trying to keep the general architecture > clean. > > >> > > > As I said, I did not made this particularly for an application, my wall > > > application is merely a demo. When we want to do something like a > > > foaf-browser we want to be able to display the resource in their > context, > > > just a usecase. > > > > Ok, so that is where our disagreement lies. The node context is in many > > case not > > at all what we want. It both adds too much information and not enough. > > > Who is "we"? You have one usecase where one should have less information > accessible via the graphnode, there are other usecase (and imho more) where > we want all information we trust). > > Wehn do we have not enough information? > > > > > > It may be that in the wall demo that is not visible. But in security > > matters and > > trust matters it will make a big difference. > > > Sorry, this seems like a demagogic null-sentence. Yes, we do care about > speed, we do care about trust and we do care about security. And the > proposed resolution of ZZ-540 and 544 brings an improvement, as it prevents > data from other trust boundaries having to be part of the base graph for > the > graphnode returned by a root-resource method. > > > > > >> > > >> Now on the whole I have learnt a lot about Clerezza by following > this, > > >> but I just can't say that this looks like > > >> a good long term solution. We are constantly moving around and around > > >> something. > > >> > > > This is your impression. I hope my explanations to the concrete points > > you > > > mention could help changing this impression. > > > > I think it should now be clear how we can come to a solution that > satisfies > > both > > our needs. > > > > Yes: you revoke your -1 and you raising an issue for getting a resource > description only from the web for your particular usecase. > [...] > > > > > > > Would the rename be okay for you to accept the proposed path? (I really > > > would like to go back to productive work, so I rather have a horrible > > name > > > than seeing the project stalled by your veto). > > > > Well then the issue would be why this class should appear in the > > CallbackRenderer. > > No I think there should be a way from JSR311 code to ask to ask precisely > > for the > > type of GraphNode it wants with very little coding. So that for the use > > cases > > where walking the content graph is the right thing to do it is one line > of > > code, > > and for cases where something more precise is needed it is also just one > > line of > > code. In any case it should be easy when reading the code to understand > > what is going > > to be displayed. > > > I don't think this is particularly hard to do, and with the issue I > proposed > you raise above even easier. > > > > > > I hope this helps, > > Maybe this thread helps understanding the clerezza architecture better. Yet > blocking development with a -1 seems quite a high price for this. > > Reto > > > > > > Henry > > > > > > > > Reto > > > > > > PS: You seem to be extensively using you're right to veto while > ignoring > > > other's veto on your code, looking at > > > https://issues.apache.org/jira/browse/CLEREZZA-515 I see that the > > commits > > > have not been reverted even more than one week after my veto and > request > > to > > > revert. > > > > Hmm, I did revert that using git. But I am not sure why that does not > > appear in the > > commits for that issue.... I see you brought that up in another thread. > > > > > > Social Web Architect > > http://bblfish.net/ > > > > >
