[
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
