Re: ISSUE-29: Re: When is equal and when is it nonequal (eg, the IRI interface)

Again, with all due respect what's the use case for having this 
additional information at all, does anybody actually need the origin for 
anything? (even if moved to the triple as toby originally suggested)

If you simply move the extra properties on to the RDFTriple then surely 
you get the same problem when testing triples for equivalence. Would you 
then be saying that two triples are not equal if they come from 
different sources?

An RDFTriple does not have any of these extra properties as we all know, 
if you are saying that a triple in RDFa does, then to me that simply means:
   RDFaTriple extends RDFTriple

On a more practical implementation level, by subclassing string you can 
get around the equivalence issues in some (but not all) languages. The 
other common and simple approach is to add an equivalence method 
o.equals(o) to interfaces which need custom equivalence testing.

All in though, I realise removing origin's all together would be a big 
change to the spec - but is there any reason not (or indeed to have them 
their in the first place, in whatever form).

Best,

Nathan

Ivan Herman wrote:
> Manu,
> 
> I do not think that having 'info' helps in any way. And I am not sure it is a different issue in the sense that it is so intimately related to equivalent testing that I am not sure how to separate them.
> 
> My assumption is, as usual, that I try to implement the API on top of some standard RDF package. That is of course a restriction, because I am bound to what the package gives me, but I think it is reasonable to suggest that a number of people will want to do that. That is how RDFLib comes into the picture for me.
> 
> A URI is a fundamental feature of those packages, so is the way to compare them for equality. It may be considered as atomic (whereas triples are not); triple comparison, internal cuisine of the package, serialization, etc, are based on that equality. If we touch that atomic unit in any way, then this may have ripple effects all around. 
> 
> In the RDFa API the URI is such an atomic unit, too. If I can map that on an RDFLib URI (call it URIRef) by simple renaming, than I can rely on the package for everything else. If I cannot, than I have to, essentially, throw away RDFLib. I do not think this should be an option.
> 
> Because RDFLib is in Python it is of course thinkable to create a subclass of RDFLib, and re-define equality for that subclass as... hm. What? (Yes, this is the issue you raised.) Is it such that a == b if a.info == b.info and a.value == b.value? That is of course wrong. But if I define a == b <=> a.value == b.value, then the underlying system will ignore the info in a bunch of places (eg, when it creates dictionaries using those class instances as keys) and things go wrong. My first attempts implementing that in RDFLib failed, and I am not sure what I would have to do. And I am not sure implementing such a subclassing mechanism with equality redefinition is a viable option for all languages in the first place!
> 
> So yes, the essence of the matter is equality, but that comes from the issue of creating a new type of atomic unit, so to say, which stores more value than just the URI.
> 
> Nathan's question is absolutely correct here: what is the use case? What is the use case that cannot be solved by having (as Toby suggested) that addition information in a triple and not in the URI?
> 
> Ivan 
> 
> 
> 
> On Aug 2, 2010, at 03:28 , Manu Sporny wrote:
> 
>> On 06/09/2010 04:53 PM, Toby Inkster wrote:
>>> On Wed, 9 Jun 2010 17:44:41 +0200
>>> Ivan Herman <ivan@w3.org> wrote:
>>>
>>>> The problem is as follows. In a package like RDFLib, the equality is
>>>> fairly simple, it is based on the equality of the URIs (let us put,
>>>> for a moment, the issue of IRI vs URI and its encoding aside).
>>>> However, our version of the IRI has two attributes: the 'value' and
>>>> the 'origin'. Ie, to IRI instances that have the same value but
>>>> different origins are different.
>>> 'origin' as specified needs fixing. Rather than:
>>>
>>> 	triple.subject.origin
>>>
>>> We should have:
>>>
>>> 	triple.subjectOrigin
>>>
>>> That way testing for equivalence between IRIs, Blank nodes and Literals
>>> becomes obvious.
>>>
>>> <> rdfs:seeAlso
>>> <http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Apr/0161.html>.
>> Unfortunately, I don't think the answer to this one is as simple as
>> that, Toby. It assumes that we're operating in a DOM environment, which
>> we can't depend on for the RDFa API.
>>
>> I've updated the RDFa API spec to move "origin" into a
>> developer-modifiable attribute called info. We also had to rename
>> "origin" to "source" due to Thomas' input on ISSUE-29. So, the way you
>> access the property at the moment is:
>>
>> triple.subject.info.source
>>
>> That's not great... definitely would like to hear some suggestions on
>> how we could make this easier on developers. The "info" mechanism is
>> meant to be a free-form developer-modifiable mechanism for storing
>> additional information along with subjects, predicates and objects. Mark
>> had asked for something like this as had Nathan and a few others.
>>
>> However, I think your and Ivan's issue has to do with equivalence
>> testing, which may be a completely separate discussion (and may need an
>> ISSUE of its own).
>>
>> AFAIK, there are two types of equivalence testing that we could do with
>> the RDFa API. The first performs equivalence testing for just the triple
>> information, that is, purely on the subject/predicate/object data
>> (including datatype and lang information).
>>
>> The second type performs equivalence testing on the information above,
>> in addition to the source Element information.
>>
>> Perhaps we should specify a section in the RDFa API that clarifies the
>> different types of equivalence testing one can do via the RDFa API. I'm
>> a bit hesitant to specify the "correct" way to do equivalence testing in
>> the RDFa API spec as there are many ways to do it.
>>
>> -- manu
>>
>> -- 
>> Manu Sporny (skype: msporny, twitter: manusporny)
>> President/CEO - Digital Bazaar, Inc.
>> blog: WebApp Security - A jQuery Javascript-native SSL/TLS library
>> http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/
>> http://blog.digitalbazaar.com/2010/07/20/javascript-tls-2/
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
>

Received on Monday, 2 August 2010 14:18:16 UTC