Hi Reto,
Sorry, but there is no real impetus for change. The status quo has to
be challenged for a change proposal of this nature, which it isn't
with only single acronyms in any of the classes we are working on
right now, even at this point with low change costs.
In addition, we are explicitly a
On 23/03/15 10:25, Reto Gmür wrote:
Right now the API on Github says nothing about the identity and hascode of
any term. In order to have interoperable it is essential to define the
value of hashcode and the identity conditions for the rdf-terms which are
not locally scoped, i.e. for IRIs and Lit
I voted for the INFRA issue, and will create it as soon as we have it
On Mon, Mar 23, 2015 at 10:42 AM, Stian Soiland-Reyes
wrote:
> Could you raise this as an issue so we can focus the discussion?
>
> Jira has not been created yet (
> https://issues.apache.org/jira/browse/INFRA-9245 ) - bu
Could you raise this as an issue so we can focus the discussion?
Jira has not been created yet (
https://issues.apache.org/jira/browse/INFRA-9245 ) - but I assume we
would import the github issues one way or another?
On 23 March 2015 at 10:25, Reto Gmür wrote:
> Right now the API on Github sa
Right now the API on Github says nothing about the identity and hascode of
any term. In order to have interoperable it is essential to define the
value of hashcode and the identity conditions for the rdf-terms which are
not locally scoped, i.e. for IRIs and Literals.
I suggest to take the definiti
Right now we have negectable costs of changing, later it will mean an
incompatible change.
So while I'm fully aware that "Projects using the library make their own
decisions", I nevertheless think that it is an advantage for Clerezza to
use the same convention as what will be its most important li
OK - I can see on settling BlankNode equality can take some more time
(also considering the SPARQL example).
So then we must keep the "internalIdentifier" and the abstract concept
of the "local scope" for the next release.
In which case this one should also be applied:
https://github.com/commons
+1 - if we end up with say SPARQLRDFXMLSerializer (which would be out
of scope now!) then revisit - stay with current names for now.
On 22 March 2015 at 20:56, Peter Ansell wrote:
> On 21 March 2015 at 20:25, Reto Gmür wrote:
>>> You had then gone on to refer to the case of
>>> possibly having m
