You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by "Henry Story (JIRA)" <ji...@apache.org> on 2011/03/05 09:08:45 UTC

[jira] Commented: (CLEREZZA-447) GraphNode not appropriate object to send from JSR311 code to Renderlet

    [ https://issues.apache.org/jira/browse/CLEREZZA-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002950#comment-13002950 ] 

Henry Story commented on CLEREZZA-447:
--------------------------------------

A workaround for this issue is to add the properties on a blank node. As the current engine does not use inference this will avoid clashes between what is stated by other systems and what is stated locally.

Nevertheless this does not seem like a good idea longer term. It could make turning on inferencing at some point in the future tricky, since the remote resources could add relations that give this blank node an identity. 

I will work with the bnode for a bit, just to get a better feel for the problem until the correct solution becomes clearer.

> GraphNode not appropriate object to send from JSR311 code to Renderlet
> ----------------------------------------------------------------------
>
>                 Key: CLEREZZA-447
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-447
>             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: http://www.atlassian.com/software/jira