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

Sounds to me like uri.info.source could be replaced with named graphs. You could then assert statements on the graph as a subject, for instance it's source. Thus would allow you to keep the provenance of different information sets separate.

RDFLib can do this, as can my own RdfContext.

This is moving us beyond pure RDF, but in a direction the community seems ti be going in anyway.

Gregg Kellogg
Sent from my iPhone

On Aug 1, 2010, at 9:57 PM, Ivan Herman <ivan@w3.org> 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 05:41:00 UTC