2011/6/3 Reto Bachmann-Gmuer <[email protected]> > On Jun 3, 2011 2:27 PM, "Tommaso Teofili" <[email protected]> > wrote: > > > > 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. > Hi Tommaso > > I don't see exactly where you see a compromise solution. Henry is proposing > syntactic sugar to create union graphs by specifying uris naming the graphs > of the union and to get a graph from the web given a uri the graph can be > assumed to contain a description for. As well as a shortcut for creating > graphnode with a uniongraph as base graph. I have no objection against any > of these issues. > > But what is the compromise? Do i have to promise I'll be implementing this > (or to accept any patch) for my zz-540 patch to be acceptable? >
no sorry, there is a misunderstanding here, I should have quoted the following text I was referring to : > 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. this seemed to me close to my idea "if you don't need GraphNodeProviderService then don't use it" , that's what it seemed to me closer to a compromise. > > 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 > > We 're voting on a patch. If the -1 one remains i'll remove it. But i think > the 4 people voting in favour of the patch should know why this patch is > considered to pollute the design of clerezza. > > Cheers, > Reto > > 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/ > > > > > > > > > > > >
