- From: Nathan <nathan@webr3.org>
- Date: Mon, 11 Oct 2010 16:52:50 +0100
- To: Manu Sporny <msporny@digitalbazaar.com>
- CC: RDFA Working Group <public-rdfa-wg@w3.org>, Tim Berners-Lee <timbl@w3.org>
Manu Sporny wrote: > On 10/11/2010 04:19 AM, Nathan wrote: >> perhaps if we ask "why not add it?", is there a good reason not to? > > Yes, there are several very good reasons not to: 1) it adds another way > of creating CURIEs whose benefits are not clear 2) it requires the > creation of an object to specify a CURIE, 3) it requires the developer > to manage the CURIE separately from the RDFa API and 4) It is more > complex than necessary. regarding 1) my proposal uses exactly the same code as the current API, all that's changed is the return type of setMapping() regarding 2) I guess, but it's less of an RDF Interface style object and more of a shortcut to the resolveCurie functionality with the first field auto-populated. regarding 3) It doesn't require the CURIE to be managed separately, indeed it's tied right in with the entire API and why I suggested the return-from-setMapping approach regarding 4) not sure I follow the more complex line of thought, please do see: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0116.html > When we did the second pass of the design phase on the RDFa API, we > attempted to make sure that it was a simple as possible for those not > familiar with RDF. We wanted to make sure that people could use the API > without having deep knowledge about "Namespaces" or CURIEs. We wanted to > make sure that people didn't have to create objects just in order to > specify an IRI. In short, we ensured that only strings were used to > interface with the RDFa API. > > In other words, creating an object just to create a CURIE was an > anti-pattern. We didn't want people to do this: > > doSomething(foaf('name')); > > Instead, we wanted this: > > doSomething("foaf:name"); > > We believe that the second is easier to understand (it's just a string, > which is interpreted in one way - via the Context), it's more compact > and leads to more readable code. the namespace proposal I suggested does ensure things are interpreted one way, via the context - this ensuring resolution always happens via `context` was a primary reason behind the approach I suggested. > What's wrong with this (which is supported by the current API)? > > var t1 = data.createTriple(me, "rdf:type", "foaf:Person"); > > Why do we need to make it any more complicated than that? Well because it isn't supported by the current RDFa API, it's strictly typed.. createTriple (in RDFResource subject, in IRI property, in RDFNode object); and has to be strictly typed, otherwise we have to make the createTriple method either fail silently or throw exceptions.. and there's no way to tell if you mean the string "foaf:Person" or the CURIE "Foaf:Person" (same problem with blank nodes), and no way to set the language of a plain literal or the type of a typed literal, and so on. The proposal was to keep the whole thing strictly typed whilst adding in optional support for namespace-style functionality (short, usable syntax) - note that foaf('name') returns IRI hence keeping everything strictly typed. Best, Nathan
Received on Monday, 11 October 2010 15:53:36 UTC