- From: Nathan <nathan@webr3.org>
- Date: Mon, 02 Aug 2010 03:20:25 +0100
- 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: - IRI - 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 arguments. Best, Nathan 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