incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <>
Subject Re: [jira] Created: (CLEREZZA-447) GraphNode not appropriate object to send from JSR311 code to Renderlet
Date Sun, 27 Feb 2011 17:45:09 GMT
A few remarks:
- which renderlet is chosen is not random but bases on the type-priority list
- a graphnode is to respond an arbitrary resource describe by the graphnode
- when returning a graph (or mgraph) the typerendering system isn't called
- you can return arbitrary object and use mbw for rendering them (default jax-rs way)
- the reason for the typerenderin system is that this allows selection of renderlet based
on the rdf type rather than java-type
- i don't see a security problem: the client needs read right to any of the triple collections
in a graphnode, how this data is rendered to non-rdf formats is the business of the delivering
instance, not the producer of the data. A renderlet cannot (at least shouln't)access more
data than what the client could also get when requesting rdf.
- Only admins can read the system graph, so this is not returned with normal requests
- there is a semantic difference between say a skos:Concept and the page on which the foaf-topic
is shown, only the latter could well be a :HeadedPage
- in your example you would most likely get a security exception, because its unlikely the
client has the right to add those triples. A get-request shouldn't have any side-effect, so
no triples should be added (except of course to a graph that isn't stored)
- in the general case the resource <http://foo/s?q=> is distinct from
<>. The first is controlled by foo, the root resource should add triples
too the first one (when generating a response graph on the fly).
- you shouldn't add triples to tell the system what to do (assuming this is what you mean
by "routing information"), rather you should add triples that are true about the requested
resource and the system should do the best given this facts and the client request. (Its app
to the application to decide in what world of evaluation the triples have to be true).


----- Original message -----
> GraphNode not appropriate object to send from JSR311 code to Renderlet
> ----------------------------------------------------------------------
>                                   Key: CLEREZZA-447
>                                   URL:
>                           Project: Clerezza
>                     Issue Type: Bug
>                         Reporter: Henry Story
> The main reason for Clerezza (zz) having an RDF engine is so that one
> can fetch data off the web and use it to guide the logic of what is
> going on. When that is done one has to carefully distinguish what is
> said or believed by different parts of the engine. *Who* believes
> *what*, is very important,   and not making that distinction will create
> security holes. 
> So for example the following is problematic. When a @GET annotated
> method returns a GraphNode in a JSR311 class one has to add information
> to   that returned GraphNode that is going to decide which Renderlet gets
> called next. Something like
>         resultNode.addProperty(RDF.`type`, PLATFORM.HeadedPage)
>         resultNode.addProperty(RDF.`type`, CONTROLPANEL.ProfileViewerPage)
> But what if the JSR wants to return a graph that is not controlled by
> the System? What if it wants to return a graph found on the internet in
> order to display it. It would have to write something like   this:
>     @GET
>     def viewPerson(@Context uriInfo: UriInfo, @QueryParam("uri") uri:
> UriRef): GraphNode = {        val foaf: GraphNode =
> descriptionProvider.getWebDescription(uri, Cache.Fetch)        val resultNode:
> GraphNode = new GraphNode(new
> UriRef(uriInfo.getAbsolutePath.toString),foaf.getGraph)   
>     resultNode.addProperty(RDF.`type`, PLATFORM.HeadedPage)   
>     resultNode.addProperty(RDF.`type`, CONTROLPANEL.ProfileViewerPage)       
> return result    }
> But now it has mixed system information with remote information. This
> means that if the foaf profile contained some different type
> information, perhaps set by a different instance of Clerezza, the ZZ
> instance will be randomly selecting one of many Renderlets, some of
> which were not chosen locally. This will completely confuse the display
> logic in the system.
>     Such a JSR 311 method must instead return a more complex object,
> consisting of a system graph perhaps and a content graph. The System
> graph is the only one that should be   considered for routing
> information. 
> -- 
> This message is automatically generated by JIRA.
> -
> For more information on JIRA, see:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message