[jira] [Commented] (CLEREZZA-489) naming of graphs

["Henry Story (JIRA)" <ji...@apache.org>]

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

Henry Story commented on CLEREZZA-489:
--------------------------------------

There was quite a bit of thinking on this issue also in CLEREZZA-463.

Let me just copy and paste what I wrote from there to here. Not sure how much I still agree with it, but it will be more help here.

<quote>
" the local caches I think should be named differently from the remote graph." 

ideally local graphs should have relative URIs. Then the coder would not need to know what the local deployment hostname is when developing his code. This is similar to how rdf/xml allows one to write relative URIs in the XML, or how one can use relative URLs in N3, or indeed in HTML. These allow the editor to see how his documents link together on the file system before someone publishes them on a server. In fact that is also how JSR311 works. If this is found to be problematic with current instantiations of RDF, then at least the API could hide whatever other system is used to get around limitations in RDF stores such as adding http://zz.localhost before a relative URI. 

But in a world where local graphs had relative URIs only things would be locally good, but it would not allow that good a communication with the external world, because the local system would not know when foreign servers were speaking about it. To be aware of global communication the local system does need to know about where foreign documents are linking to the local documents. Though this is not such a big deal either. 

Remote graphs as I mentioned are easiest named after the remote resource from which they come, especially in a graph database. One could decide that every graph stored locally is just a temporary representation of a remote graph, which would be useful for temporal reasoning - to keep track of changes to versions of a resource for example. To push that logic further one may want to distinguish in a multi user system between graphs for the same resource when requested by different people, as explained in great detail in CLEREZZA-490. It is clear then that naming a remote graph by the URL of the resource of that remote graph is not the final solution. But unless we have a function from (user, time, URI) -> graph then giving the resource the name of the graph is certainly the easiest, as it makes reading the database a lot easier: one just needs to look at the name of a graph to know where it came from. 

The fully correct system for remote graphs would be something like this in n3 

:g202323 a :Graph; 
    = { ... }; 
    :fetchedFrom <https://remote.com/&gt;; 
    :fetchedBy <http://bblfish.net/people/henry/card#me&gt;; 
    :representation <file:/tmp/repr/202323>; 
    :httpMeta [ etag "sdfsdfsddfs"; 
                     validTo "2012...."^^xsd:dateTime; 
                    ... redirected info? 
                    ] . 

:g202324 a :Graph; 
    = { ... }; 
    :fetchedFrom <https://remote.com/&gt;; 
    :fetchedBy <http://farewellutopia.com/reto#me&gt;; 
    :representation <file:/tmp/repr/202324>; 
    :httpMeta [ etag "ddfsdfsddfd"; 
                     validTo "2012...."^^xsd:dateTime; 
                    ... redirected info? 
                    ] . 


This would allow the proxy to: 
   - be much more useful in debugging, say when a remote document is broken it can help the user see where that is 
   - know when to fetch new remote representations 
   - know to distinguish representations sent to different users 

It is arguable that the better the remote systems are written, the more RESTful they are, the more the name of the remote graph can be the name of the remote resource, since they will be names of unchanging entities. Given that we could start with naming the remote graphs the RESTful way, as that is easiest and most likely to force us to be RESTful ourselves. 
</quote>

       

> naming of graphs
> ----------------
>
>                 Key: CLEREZZA-489
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-489
>             Project: Clerezza
>          Issue Type: Brainstorming
>            Reporter: Henry Story
>
> I keep getting lost in the WebProxy code on what graphs are named what. It would be easiest if graphs were named by the URL they were fetched from. The expectation would then be that the graph named something is what I get when I do a curl -H "Accept: application/rdf+xml" url
> So when running my localhost instance the graph from <http://bblfish.net/people/henry/card> should have that same name and not
> <http://bblfish.net/people/henry/card.cache> or some other name.
> local graphs can just have the url of the local server, eg on bblfish.net:8443
> the admin graph would be named 
>   <https://bblfish.net:8443/user/admin>
> and not
>    <https://bblfish.net:8443/user/admin.graph>
> There won't be any clashes between remote and local graph of course, since we are all in one namespace: urls.
> The only thing I remember being needed is if one wanted a local graph to have additional information about a remote user. But that would be easy. The local information would be placed in a local graph such as
> <https://bblfish.net:8443/user?id=$urlencode{remoteid}>
> That makes clear where the responsibility for that URL lies - with bblfish.net, not with the remote server as it does in the {remoteid}.cache notation. Of course it could also be at
> <https://bblfish.net:84432/user/hash1231> or any other local url.
> So how would one know what the local addition to a remote graph is? I think that is application specific anyway. It requires a function to map from remote graph to a local transformation for each app that requires such a thing. 
> Things can be made to be more complicated, but I think it helps if to start with these things are as transparent as possible.
> I would like to implement this for the WebProxy and the WebID login. I just keep getting lost as I said with what graph is what.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira