[
https://issues.apache.org/jira/browse/CLEREZZA-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003364#comment-13003364
]
Henry Story commented on CLEREZZA-447:
--------------------------------------
The workaround of adding blank nodes with properties is not very satisfactory.
1. One ends up with a lot of mini graphs growing off a blank node such as
[] a <http://clerezza.org/2009/08/platform#HeadedPage> ,
<http://clerezza.org/2009/03/controlpanel#ProfileViewerPage> ;
<http://xmlns.com/foaf/0.1/primaryTopic>
<http://bblfish.net/people/henry/card#me> .
which bring nothing to the understanding of the graph and should all end up
being smushed.
2. The meaning of such a graph is not intuitive at all. It just says that
there is a ProfileViewerPage with a primaryTopic that is a given agent. Where
that profile Viewer page is is not indicated. So that makes for a pretty
useless mini graph.
A SOLUTION
===========
A semantically correct solution would be to have the page return a graph such as
<http://localhost:8080/user/admin/people?uri=http://bblfish.net/people/henry/card>
a zz:HeadedPage, zz:ProfileViewerPage ;
foaf:primaryTopic <http://bblfish.net/people/henry/card#me>;
zz:asSeenBy <http://localhost:8080/user/admin/profile#me> .
Or something equally small and simple.
If N3 were really implemented then one could add
<http://bblfish.net/people/henry/card> log:semantics { .... }
This would allow the server to state what it knows about a remote resource. But
given that I think all triple stores are dragging their heels on implementing
N3 correctly, we will have to wait for this. The advantage is that it helps
keep things simple to start off with. We don't yet have a use case for adding
these triples, so let us not add them.
In any case this will require the SSP layer to have access to cached remote
graphs. But I think this is not an unreasonable thing to ask for. The
RenderedPage ssp could have a method
getMGraphFor(uri)
And so Scala Server Pages could use URIs found in the res graph given to them,
to build more complex views in html, by fetching information stated remotely.
If RDFa allowed one to use named graphs, then one could describe that
relationship between the main page and the remote one more clearly. User
interactions would then be ones of accepting remote information in the local
graph store for example.
Expansion
========
Here are some sketches of thoughts of where this could lead to, which I put
here just in order to help fill out the picture above a little.
If we take the route described above, there would seem to be a content
difference between the HTML and the rdf/xml representations. Above I explain
this as being due to the limited availability of named graph semantics in the
rdf representation formats. So HTML without RDFa can of course say a lot more -
in human language - than we have yet agreed to make formally available at
present.
But the html will presumably be a form of some sort, that would allow the end
user to express an action such as:
- I want to add person X to my friend list
- I also accepts facts F1, F2, F3 ... as true when expressed about X.
Perhaps could be made explicit by having a relation to an RDF form (when
someone gets around to specifying that)
<> acceptTriples
<http://localhost:8080/user/admin/people/http/bblfish.net/people/henry/card>.
or something along those lines. Then as the user accepts information from those
graphs, those triples - say picture of a user, his name, and so on can be added
locally there.
If one can express this in RDF then it makes it possible to later create more
complex clients that do the same as the server does now by reading the RDF
graph returned for the profile viewer page. In fact it would be I claim a proof
of good design to make this possible.
> 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
