You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org> on 2011/05/13 14:28:47 UTC

[jira] [Created] (CLEREZZA-525) Refactory Werbproxy

Refactory Werbproxy
-------------------

                 Key: CLEREZZA-525
                 URL: https://issues.apache.org/jira/browse/CLEREZZA-525
             Project: Clerezza
          Issue Type: Improvement
            Reporter: Reto Bachmann-Gmür
            Assignee: Reto Bachmann-Gmür


The current api has many undocumented public methods and it seems to make an unsharp distinction between the caching (and respective access) of graphs and of graphnodes.

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

[jira] [Commented] (CLEREZZA-525) Refactory Werbproxy

Posted by "Henry Story (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CLEREZZA-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033057#comment-13033057 ] 

Henry Story commented on CLEREZZA-525:
--------------------------------------

no issue there that WebProxy needs a lot of improvement.

> Refactory Werbproxy
> -------------------
>
>                 Key: CLEREZZA-525
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-525
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Reto Bachmann-Gmür
>            Assignee: Reto Bachmann-Gmür
>
> The current api has many undocumented public methods and it seems to make an unsharp distinction between the caching (and respective access) of graphs and of graphnodes.

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

[jira] [Updated] (CLEREZZA-525) Create caching storageprovider retrieven triple-collections from the web

Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CLEREZZA-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Reto Bachmann-Gmür updated CLEREZZA-525:
----------------------------------------

    Summary: Create caching storageprovider retrieven triple-collections from the web  (was: Refactory Werbproxy)

> Create caching storageprovider retrieven triple-collections from the web
> ------------------------------------------------------------------------
>
>                 Key: CLEREZZA-525
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-525
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Reto Bachmann-Gmür
>            Assignee: Reto Bachmann-Gmür
>
> The current api has many undocumented public methods and it seems to make an unsharp distinction between the caching (and respective access) of graphs and of graphnodes.

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

[jira] [Commented] (CLEREZZA-525) Refactory Werbproxy

Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CLEREZZA-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033622#comment-13033622 ] 

Reto Bachmann-Gmür commented on CLEREZZA-525:
---------------------------------------------

Added a new project with WebProxy in package org.apache.clerezza.rdf.storage.web. This exposed both a WebProxy service as well as a regulat WeightedTcManager. Cleint applications that do not wont to force a particular CacheUpdatePolicy should not use this interface but rather access all TripleCollections via TcManager. Only clients that want to enforce an update policy should access the org.apache.clerezza.rdf.storage.web.WebProxy service.

TODO: We should provide a virtual graph from which meta information about the cached graphs can be retrieved. E.g. time of last retrieval, connection security, etc.

> Refactory Werbproxy
> -------------------
>
>                 Key: CLEREZZA-525
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-525
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Reto Bachmann-Gmür
>            Assignee: Reto Bachmann-Gmür
>
> The current api has many undocumented public methods and it seems to make an unsharp distinction between the caching (and respective access) of graphs and of graphnodes.

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

[jira] [Closed] (CLEREZZA-525) Create caching storageprovider retrieven triple-collections from the web

Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CLEREZZA-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Reto Bachmann-Gmür closed CLEREZZA-525.
---------------------------------------

    Resolution: Fixed

Implemented and added minimalistic implementations, new issues should cover cachen invalidation. Part of the code taken from Clerezza 463

> Create caching storageprovider retrieven triple-collections from the web
> ------------------------------------------------------------------------
>
>                 Key: CLEREZZA-525
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-525
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Reto Bachmann-Gmür
>            Assignee: Reto Bachmann-Gmür
>
> The current api has many undocumented public methods and it seems to make an unsharp distinction between the caching (and respective access) of graphs and of graphnodes.

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

[jira] [Closed] (CLEREZZA-525) Create caching storageprovider retrieven triple-collections from the web

Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CLEREZZA-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Reto Bachmann-Gmür closed CLEREZZA-525.
---------------------------------------

    Resolution: Fixed

I replied on the list for the platform related usecase, what you think is bug turns out to be a feature as it allows for example an uploaded turtle document to be used in a sparql query (while the turtle document is still available at its uri including orginal formatting ans comments).

but even if this wasn't case, the patch is a solution for the issue at hand which does not concern the platform layers but the SCB layer. SCB TcManager is an APi that returns graphs given a URI naming them. Per se (i.e. rdf.core) has nothing do neither with serving graphs nor with retrieving them, the modular architecture allows multiple system to be connected. The storage provider realized in this issue connects the Semantic Web to TcManager. The semantic can be descibed as a huge set of named graphs, thanks to the resolution of this issue, these graphs are now available with TcManager.

Because of the different provider having different weights and this provider having weight 0 this ensures that it is only used when no other provider provides a graph for a specified name.

But again, if naive usage of this proxy was to create problems on the platform layer, this would be no reason to deny this useful client library on this layer. Rather one should address this problems on the layer they show up, but as per now I don't see a situation in the platform where using the proxy creates fundamental problems.

> Create caching storageprovider retrieven triple-collections from the web
> ------------------------------------------------------------------------
>
>                 Key: CLEREZZA-525
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-525
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Reto Bachmann-Gmür
>            Assignee: Reto Bachmann-Gmür
>
> The current api has many undocumented public methods and it seems to make an unsharp distinction between the caching (and respective access) of graphs and of graphnodes.

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

[jira] [Reopened] (CLEREZZA-525) Create caching storageprovider retrieven triple-collections from the web

Posted by "Henry Story (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CLEREZZA-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henry Story reopened CLEREZZA-525:
----------------------------------


According to recent e-mail discussion, a Proxy Storage that does not know what the name of the machine it is running on is, is problematic.

http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201105.mbox/browser

[[

On 15 May 2011, Reto Bachmann-Gmuer wrote:
> We don't know the names of the current machine, remember that we are
> operating on the rdf access layer (SCB) here. Unlike the WebId service
> this is not on the platform service.

Well perhaps it is at the wrong layer then. Perhaps a WebProxy, being at the web layer needs
to know the name of the service it is running as. Please read through the following  reasoning
carefully before replying.

Consider that the API you are developing has the following method

     def getGraph(name: UriRef)

If the WebProxy services is called like this:

wp.getGraph("https://bblfish.net/user/admin/".uri)

Then it certainly would be very useful for the proxy service to know that bblfish.net is the
local machine, and that it does not need to do an httpS GET to discover the graph. 

A use case can help illustrate this. Imagine a zz service looks at a foaf file that contains
a reference to <https://bblfish.net/user/admin/#me> It sends the request to the cache
proxy to fetch the file so that it can find out more about that resource. What is it? A fish,
a mineral, a human, or an ontology?  So it goes to the web proxy and calls it above. If your
proxy looks in its
  
    urn:x-localinstance:/cache/

namespace it won't find a reference to our URL above. So it will do a GET on the web, find
it,
and place it in 

    urn:x-localinstance:/cache/https://bblfish.net/user/admin/


Now imagine I then update my bblfish.net profile. The next time my zz instance will go and
look in the proxy it will find the above urn and look up the information there. Not only will
we now have the information twice in the database, we will end up getting out of date information
for our own data!
]]

> Create caching storageprovider retrieven triple-collections from the web
> ------------------------------------------------------------------------
>
>                 Key: CLEREZZA-525
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-525
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Reto Bachmann-Gmür
>            Assignee: Reto Bachmann-Gmür
>
> The current api has many undocumented public methods and it seems to make an unsharp distinction between the caching (and respective access) of graphs and of graphnodes.

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