Re: RDFa API - adding Namespace

On 10/11/2010 11:52 AM, Nathan wrote:
> 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()

What I meant is that up to this point there was one way of specifying
and resolving a CURIE. With your proposal, there would be two ways of
doing so, correct?

Having two mechanisms isn't bad, in and of itself, but the question I'm
asking is whether or not we need another mechanism. We're asking
developers to be aware of two mechanisms when just one mechanism would
work just fine (at least, that's what I'm asserting).

> 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.

Why not this?

var c = document.data.context.resolveCurie;
c("foaf:name");

Sure, the first field isn't auto-populated, but you end up writing
"foaf" anyway - foaf('name') vs. c("foaf:name") - the added bonus is
that we're not switching the API syntax on people. This approach also
allows developers to call the utility function whatever they'd like,
whether it is 'ns', 'prefix', 'expand', 'curie', or something else.

> 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

I think we do have to manage it separately, let me explain - think of
this in context. Using the mechanism you describe, assume that we have a
bunch of Javascript. At the top of file #1, we have:

function setup()
{
   ...
   var foaf = document.data.context.setMapping("foaf", "http://....");
   ...
}

Then in file #2, we have:

function doAction()
{
   ...
   var t = document.data.store.createTriple(me, foaf('name'), "Nathan");
   ...
}

How does the foaf function get from setup in file #1 to the doAction
function in file #2? Does this mean we need a getMapping() call as well?
Or do you mean that we need to store the 'foaf' function pointer
somewhere? In either case, don't you think that is more complicated than
the method outlined above?

> 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

We can already do this with the current API, can't we? Why is this not
sufficient?

var c = document.data.context.resolveCurie;
var t1 = data.createTriple(me, c('rdf:type'), c('foaf:Person') );
var t2 = data.createTriple(me, c('foaf:givenname') , myName );
var t3 = data.createTriple(me, c('foaf:homepage') , myHomepage );
var t4 = data.createTriple(me, c('foaf:knows') , c('mydoc:bob') );
var t5 = data.createTriple(me, c('foaf:knows') , c('mydoc:sue') )

>> 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.

We're mis-communicating. What I meant was that when someone is scanning
a document for mentions of a CURIE, there are two patterns that they
need to look for with the approach you outlined:

foaf('name') /and/ "foaf:name"

vs. what we have now, which is one pattern:

"foaf:name"

The assertion is that it's easier to scan for one type of pattern in
code, and understand how that one pattern is mapped to an IRI than two
patterns. The less cognitive load we place on RDFa API developers, the
better off they are.

>> 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.

Right, good point.

I think the points above still stand, what do you think?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Saving Journalism - The PaySwarm Developer API
http://digitalbazaar.com/2010/09/12/payswarm-api/

Received on Tuesday, 12 October 2010 00:23:55 UTC