- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 10 Jun 2010 10:27:54 +0200
- To: Toby Inkster <tai@g5n.co.uk>
- Cc: W3C RDFa WG <public-rdfa-wg@w3.org>
- Message-Id: <0283D4D1-54D3-44A0-BD5B-3D8DF2C05E37@w3.org>
On Jun 9, 2010, at 22:53 , 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>. > Ah, I must admit I did not remember that one. Yes, testing equivalence for IRIs, Literals, etc, become obvious. However, that still means that, in <div about="a:b" property="p:p" resource="q:q">bla bla</div> <div about="a:b" property="p:p" resource="q:q">bla bla something else</div> the two _triples_ are different in the API, while they are not as RDF triples. Put it another way, the model for our stores is, say, a 6-store,... (or a quadstore with the fourth item packaging information about the 3 DOM nodes). It should still be made very explicit, including the fact that if the graph is serialized, the fourth entry should be forgotten and triples should be, possibly, merged... Ivan > -- > Toby A Inkster > <mailto:mail@tobyinkster.co.uk> > <http://tobyinkster.co.uk> > ---- 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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 10 June 2010 08:26:26 UTC