- From: Nathan <nathan@webr3.org>
- Date: Mon, 02 Aug 2010 17:50:28 +0100
- To: Toby Inkster <tai@g5n.co.uk>
- CC: Manu Sporny <msporny@digitalbazaar.com>, Ivan Herman <ivan@w3.org>, W3C RDFa WG <public-rdfa-wg@w3.org>
Toby Inkster wrote: > On Sun, 2010-08-01 at 21:28 -0400, Manu Sporny wrote: >> 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 > > What it's called does not matter so much to me. What I'm concerned about > is that the origin is being attached to the IRI, PlainLiteral, > TypedLiteral and BlankNode interfaces when it's more useful if attached > to the RDFTriple interface. agree to a point, but doesn't this just boot the equivalence problem to the RDFTriple level instead, where two identical triples (s,p,o wise) are no longer identical because they have different node origin's etc. I'll ask again - does anybody actually have a use case for needing the origin's at all? What's wrong with just: { "subject" : { "value" : "http://tobyinkster.co.uk/#i" }, "predicate" : { "value" : "http://xmlns.com/foaf/0.1/name" }, "object" : { "value" : "Toby Inkster" } } If I need to find a node by subject, then there are handy methods to do this already. Best, Nathan
Received on Monday, 2 August 2010 16:51:16 UTC