incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CLEREZZA-533) TcProvider does not (should not?) dereference URIs with hash
Date Sun, 22 May 2011 01:53:47 GMT

    [ 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

Mime
View raw message