W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > August 2010

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

From: Nathan <nathan@webr3.org>
Date: Mon, 02 Aug 2010 03:20:25 +0100
Message-ID: <4C562B69.8090405@webr3.org>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: Toby Inkster <tai@g5n.co.uk>, Ivan Herman <ivan@w3.org>, W3C RDFa WG <public-rdfa-wg@w3.org>
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.
> 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.

Here's how I see it - the following are *not* specific to RDFa:
- PlainLiteral
- TypedLiteral
- RDFTriple

negating everything even remotely debatable, IRI is global, an IRI is an 
IRI and whilst an IRI certainly has a value, an IRI definitely 100% most 
certainly does not have an origin, or a source, or an info.source or 
anything of the like.

The same argument goes for all the aforementioned, work outside the 
scope of RDFa API for just a moment and you'll see that these are all 
global and you can't modify or define them in anything other than a 
globally valid way.

Now - apologies in advance for this...

What's the use-case for having the origin/source?
What's the use-case for having store.createIRI(iri,origin);?
  (and all related)

If you have some use-case(s), can they be handled by functions like 
document.getElementsBySubject(type) or not?

 From every angle I look it that, I can't for the life of me see a 
use-case, can't see any reason for them to be there, and at every turn 
they make everything more complicated.

Hence the obvious suggestion, remove all the origin properties and 



ps: hope I didn't come across as rude at all - if so, it wasn't intended!
Received on Monday, 2 August 2010 02:21:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:48 UTC