Re: RDFa API - adding Namespace

On 2010-10 -11, at 20:23, Manu Sporny wrote:
> Why not this?
> 
> var c = document.data.context.resolveCurie;
> c("foaf:name");

Well. any context is messy when it comes to clean software engineering.
Where do you get the context from? If one person writes a library and
the other person uses it, do they have to agree on the prefixes they use?
If so, the system breaks silently when people in the future change or remove 
prefixes.  A design with context in is more complicated than one without.

When you do

var foaf = $rdf.Namespace("http://...")

then foaf the variable can be used anywhere with no context.


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


Switching the API syntax from what? The API syntax doesn't have to use curies.
Curies coem from XML.  The art of a good Javascrpt API is to make the syntax
as natural as possible for Javascript.

> This approach also
> allows developers to call the utility function whatever they'd like,
> whether it is 'ns', 'prefix', 'expand', 'curie', or something else.

you can surely always do that in js anyway:

	var ns = $rdf.Namespace;


> 
>> 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");
>   ...
> }


Well, you typically have some thing which is passed around in the application, (like $ in jquery, or tabulator in the tabulator code) sometimes global,  or set up at the beginning of each file.


You can do something like

{
	if (typeof house == 'Undefined')  house = {};
	house.ns = {};
	house.ns.foaf =  $rdf.nspa("http://...");
}

Not sure at al that I answered your question.


> 
> 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') );

That will work.

> var t2 = data.createTriple(me, c('foaf:givenname') , myName );
> var t3 = data.createTriple(me, c('foaf:homepage') , myHomepage );

No, this will not work.
You must distinguish between a literal string "http://whatever" and a symbol <http://whatever>..


> var t4 = data.createTriple(me, c('foaf:knows') , c('mydoc:bob') );
> var t5 = data.createTriple(me, c('foaf:knows') , c('mydoc:sue') )

Yes, that will work.



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

That was what happened in the RDF/XML design and it was to a certain
extent a disaster.   It is much more important to make it very 
clean for this who do understand RDF, and then people will actually
learn RDF that much faster.  RDF is very simple, in fact.

>>> We wanted to make sure that people could use the API
>>> without having deep knowledge about "Namespaces" or CURIEs.

Well, any way people have practically read or written RDF has always
used some form of prefix, except for NTRiples, which is unreadable and unwritable
and only used for  test files.

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

For an RDF string, use a string.
For an RDF number, use a number.
For an RDF list, use a list.

For symbols (RDF nodes identified by IRIs) you can pass the whole string but it 
it normally a total pain, and you really want to use a prefix.


>>> In other words, creating an object just to create a CURIE

You are not creating a curie.
RDF graphs don't have curies in them.
You are creating an RDF node which has a URI.

>>> was an
>>> anti-pattern. We didn't want people to do this:
>>> 
>>> doSomething(foaf('name'));
>>> 
>>> Instead, we wanted this:
>>> 
>>> doSomething("foaf:name");

The first is better Javascript
I wish we could write doSomething(foaf.name)
That is nice Javascript.
Maybe in a later Javascript.
(Hey, maybe Javascript will one day have doSomething(foaf:name);, but it doesn't yet.)

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

That's assuming the document they are looking at is 50/50 HTML and JS.
I bet tha

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

I don't think they do.
You have to figure out what you are going to pass.
You have to allow someone to either use a prefixed URI or a full long URI or give a string or a number (or a Date).
I've been writing lots of javascipt and I am happy to learn new tricks but I am sure that the 
user needs a consistent model and a simple compose-able rules.


document.data.add(me, foaf('knows'), you);
d = document.data
d.add(me, foaf('name'), "John Doe");
d.add(me, foaf('knows'), mydoc('sally');
d.add(me, foaf('age'), 3);
d.add(me, foaf('kidsAges'), [10, 6]);   // Makes an RDF Collection
d.add(me, foaf('dob'), new Date('1921-09-19'));  // Makes the right datatype

Where any of the three parameters to add can take any of the forms (modulo the RDF model).
The aim is to coerce from the natural javascript to the appropriate RDF in a very consistent way.

Tim


> 
> -- 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 03:51:50 UTC