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/17 23:01:47 UTC
[jira] [Created] (CLEREZZA-533) atorage.web: dont derference URIs
with hash
atorage.web: dont derference URIs with hash
-------------------------------------------
Key: CLEREZZA-533
URL: https://issues.apache.org/jira/browse/CLEREZZA-533
Project: Clerezza
Issue Type: Improvement
Reporter: Reto Bachmann-Gmür
Assignee: Reto Bachmann-Gmür
URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLEREZZA-533) atorage.web: dont derference URIs
with hash
Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Reto Bachmann-Gmür closed CLEREZZA-533.
---------------------------------------
Resolution: Fixed
The TcManager is to dereference graphs, non-information resource are not graphs. Use the GraphNodeProvider to get things like the Eiffel Tower.
> atorage.web: dont derference URIs with hash
> -------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037425#comment-13037425 ]
Henry Story commented on CLEREZZA-533:
--------------------------------------
I wrote:
>> So since WebProxy is meant for automatic dereferencing of resources, one might as well make it general enough to work on all the resources.
Reto replied:
>No its not meant for that, its about getting graphs by name.
So to use web proxy you are meant to know ahead of time what the URI means? How is that going to be automated?
Is this an optimisation problem, that we don't want to be checking the hash at the end of the URL?
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037495#comment-13037495 ]
Reto Bachmann-Gmür commented on CLEREZZA-533:
---------------------------------------------
"I find it confusing that you say that it is about StorageWeb, when the code that is changed is WebProxy which is a WeightedTcProvider. "
The code that is changed is in the only class of the artifact named storage.web.
"If TcProviders were purely about getting graphs, nothing more, then what you say would make sense."
read the api doc of TcProvider they are.
"They would be like Sesame then."
In fact we have an adaptor for Sesame
"But by placing the WebProxy into the TcProvider class hierarchy, things take on a different turn, since now a layer of web knowledge has been added."
Like a sesame store, the web is something that for a set of names can return graphs. It is not true that things take a different turn.
"Asking for a URI in a proxy is to ask for a procedure to be followed whereby you then get the graph related to the URI."
I could agree with nameing the class diffrently, maybe just WebProvider instead of WebProxy. But its clearky not about getting a graph related to the URI but its about getting the graph named by an uri.
"In that scenario a whole new layer of naming semantics has been added."
Not true
"Once you admit that this process should be started, then there is no reason now to have the system take care of hash URIs in the same way you will have to take care of uris such as http://xmlns.com/foaf/0.1/knows "
No I don't think there is a need to change the TcProvider API or the semantics of anything else. And your obstrcution
You admit that my patch is "ok as short term thing". Which means the patch is ok given current APIs and defined semantics. Yet you're blocking the patch and had me revert it, now you want to use this issue as an entry point for a discussion on changing the semantics and definitions of TcManager and TcProvider. You're free tomake such proposaly, but could you do this without squatting issues and without blocking patches which you agree the are ok at least as a short term thing especially since you're not proposing a patch for an alternative resolution.
If ProfilePanel and FoafBrowser are affected by the patch I submitted they were using TcManager in a wrong way (not as specified by the API), the two classes are definitively not related to the task of throwingNoSuchEntityExceptions for names for which we have no reason to believe that they denote graphs
Please revert the commits you made for this issue
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037417#comment-13037417 ]
Henry Story commented on CLEREZZA-533:
--------------------------------------
I vote to undo the patch.
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henry Story updated CLEREZZA-533:
---------------------------------
Summary: TcProvider does not (should not?) dereference URIs with hash (was: atorage.web: dont derference URIs with hash)
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLEREZZA-533) atorage.web: dont derference URIs
with hash
Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Reto Bachmann-Gmür closed CLEREZZA-533.
---------------------------------------
Resolution: Fixed
> atorage.web: dont derference URIs with hash
> -------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037493#comment-13037493 ]
Henry Story commented on CLEREZZA-533:
--------------------------------------
"I find it very confusing that the issue has been renamed, this issue is not about TcProvider in general but about storage.web. "
I find it confusing that you say that it is about StorageWeb, when the code that is changed is WebProxy which is a WeightedTcProvider.
If TcProviders were purely about getting graphs, nothing more, then what you say would make sense. They would be like Sesame then. But by placing the WebProxy into the TcProvider class hierarchy, things take on a different turn, since now a layer of web knowledge has been added. Asking for a URI in a proxy is to ask for a procedure to be followed whereby you then get the graph related to the URI. In that scenario a whole new layer of naming semantics has been added. Once you admit that this process should be started, then there is no reason now to have the system take care of hash URIs in the same way you will have to take care of uris such as http://xmlns.com/foaf/0.1/knows
But I mentioned those argumetns a few times above. So the problem is what should one do, which is why I changed the thread name to a question. Your patch is ok as short term thing, to help people realise that this issue is not fixed, and needs solving. You could put an error message pointing to this bug, to get people to come here and vote or propose solutions for when they rewrite for the nth time a hash removal code.
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CLEREZZA-533) atorage.web: dont
derference URIs with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036433#comment-13036433 ]
Henry Story edited comment on CLEREZZA-533 at 5/19/11 8:28 PM:
---------------------------------------------------------------
update to critical. I really don't want to go writing code everywhere to remove hashes, just so that a few weeks later I have to undo all that code when it becomes obvious that it is the wrong way to do things.
was (Author: bblfish):
update to critical. I really don't want to go coding everywhere against hashes, just so that a few weeks later I have to undo all that code when it becomes obvious that it is the wrong way to do things.
> atorage.web: dont derference URIs with hash
> -------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLEREZZA-533) atorage.web: dont derference URIs
with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henry Story updated CLEREZZA-533:
---------------------------------
Priority: Critical (was: Major)
update to critical. I really don't want to go coding everywhere against hashes, just so that a few weeks later I have to undo all that code when it becomes obvious that it is the wrong way to do things.
> atorage.web: dont derference URIs with hash
> -------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037424#comment-13037424 ]
Henry Story commented on CLEREZZA-533:
--------------------------------------
So of course then the issue is that there is the danger of naming graphs locally that have a hash, which should certainly be avoided, as I myself reported in CLEREZZA-538 .
But here it is easier, because all locally named graphs can be controlled. Before creating a graph remove the hash. For remote graphs the same can be done, but it could be improved by using the status codes to work out what the real name of the graph is. So it is only in such a way that one can work out what the name of the foaf:knows graph is.
It would be worth working out in details what the answer to that should be in due course in fact. And so this brings us back to the thread on graph naming.
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037491#comment-13037491 ]
Reto Bachmann-Gmür commented on CLEREZZA-533:
---------------------------------------------
Ok, Reverted my change as asked for by Henry.
I find it very confusing that the issue has been renamed, this issue is not about TcProvider in general but about storage.web.
I'm still convinced that the issue is legitimate and my proposed patch appropriate.
Argument:
Premises:
1. TcProvider#getGraph returns a graph given the name of a graph and thorws a NoSuchEntityExcpetion if there is no such graph, i.e. a Provider should return a triple collection if such a graph exists or can reasonable be assumed to exits and throw an exception otherwise
2. If on the web I get an RDF representation doing a GET request against http://example.org/foo I have a reason to assume that <http://example.org/foo> is the name of the graph obtained by interpreting the returned representation.
3. The web gives no reason to assume that the infinity of URIs starting with http://example.org/foo#, denote a graph
Conclusion
4. storage.web should return a graph for the name <http://example.org/foo>
5. storage web should throw a NoSuchEntityException for the uris starting with http://example.org/foo#
I assume you disagree with premise 1, but that's the current definition of the API, and blocking bug-fixes that are to guarantee that the implementation matches the API is not an acceptable way to propose changes to the API.
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?) dereference URIs with hash
Posted by Henry Story <he...@bblfish.net>.
On 21 May 2011, at 19:08, Reto Bachmann-Gmür (JIRA) wrote:
>
> Could you post your -1 on the list with the mandatory indication of the reason.
Why? The posts to the wiki are sent here. I wrote up my reason there. It's better because one
can keep track of issues there. And people can follow the discussion on the list too.
Henry
[jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037423#comment-13037423 ]
Reto Bachmann-Gmür commented on CLEREZZA-533:
---------------------------------------------
Could you post your -1 on the list with the mandatory indication of the reason.
To your prvious comment:
> GraphNodeProvider as described in CLEREZZA-540 does not work.
could we discuss that there
> So this does not solve that issue.
It does solve what it describes
> Furthermore there is no way to tell in advance what a URI refers to: a graph or an object.
an object is a resource in rdf terms and a graph is a resource, but TcManager is not about dereferencing anything but about getting TripleCollection, a graph with a hash does not identify a TripleCollection that's why this issue says that it should say that there is no such entity
> So since one cannot tell in advance there is no reason to make a distinction for hash uris. foaf:knows is an object and a robot may now know what it is.
See the HttpRange-14, to some degree we may discover things about the nature of resource automatically.
> So since WebProxy is meant for automatic dereferencing of resources, one might as well make it general enough to work on all the resources.
No its not ment for that, its about getting graphs by name.
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLEREZZA-533) atorage.web: dont derference URIs
with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henry Story reopened CLEREZZA-533:
----------------------------------
This seems to have been solved with this code:
if (name.getUnicodeString.indexOf('#') != -1) {
logger.debug("not dereferencing URI with hash sign")
throw new NoSuchEntityException(name)
}
Why not just remove the hash, instead at that point? After all, what happens if the URI refers to an object like the eiffel tower or a relation such as foaf:knows is dereferenced - which could very well happen in automated dereferencing schemes. Then dererferencing that URL will return a "303 See Other" and that resource will be the proper name of the graph.
My feeling is that instead of trying to get the requesting code to work out what type of resource is being requested, it would be a lot better for the Graph returned to have a field containing it's final name.
> atorage.web: dont derference URIs with hash
> -------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLEREZZA-533) atorage.web: dont derference URIs
with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henry Story reopened CLEREZZA-533:
----------------------------------
GraphNodeProvider as described in CLEREZZA-540 does not work. So this does not solve that issue. Furthermore there is no way to tell in advance what a URI refers to: a graph or an object... So since one cannot tell in advance there is no reason to make a distinction for hash uris. foaf:knows is an object and a robot may now know what it is. So since WebProxy is meant for automatic dereferencing of resources, one might as well make it general enough to work on all the resources.
> atorage.web: dont derference URIs with hash
> -------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?)
dereference URIs with hash
Posted by "Henry Story (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLEREZZA-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037634#comment-13037634 ]
Henry Story commented on CLEREZZA-533:
--------------------------------------
I recommitted the changes you made with a link to this issue.
> TcProvider does not (should not?) dereference URIs with hash
> ------------------------------------------------------------
>
> Key: CLEREZZA-533
> URL: https://issues.apache.org/jira/browse/CLEREZZA-533
> Project: Clerezza
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Assignee: Reto Bachmann-Gmür
> Priority: Critical
>
> URIs with hash do not name the graph but a resource within that graph so we should not just return the graph (which has the uri subsection before the hash sign as name)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira