Re: Latest versions of the RDFa DOM API document and JS prototype

On 04/16/2010 11:31 AM, Benjamin Adrian wrote:
> Manu Sporny schrieb:
>> The constructs, like XSD["integer"] may be better implemented as
>> properties of the global "rdfa" object, instead of as global objects
>> themselves. 
>> ...
> But where is the programming logic for this mapping?

I don't think I understand the question, could you please rephrase it or
elaborate on the question?

If the question is "where are the mappings created?" - then we could do
two things:

1. Implement a subset of mappings that all RDFa DOM API implementations
should support, like: rdf, rdfs, rdfa, xsd, skos and owl

2. Provide an external file that pre-loads a number of mappings.

3. Provide no mappings and leave it to developers to include their own
Javascript file that creates mappings when the document is loaded.

> What transforms the typed literal's value to integer in JS?

It would work similarly to what the code does right now - the
TypedLiteral object would execute the transformation. You could register
converters via the rdfa object's registerTypeConversion() function.

>> and use them like so:
>>
>> var x = new TypedLiteral("W3C", rdfa.xsd.string);
>>   
> Isn't
> 
> (rdfa.xsd.string == rdfa.xsd["string"]) == true ?

yes... technically, this should hold as well:

(rdfa.xsd.string === rdfa.xsd["string"]) == true

"===" ensures that the types match as well as the values - the result of
valueOf().

> Important is: Which vocabularies should we support?

Difficult question. I'm split between W3C-only vocabs and no vocabs at all.

If we pick a very limited set of W3C base vocabularies we may be okay
(rdf, rdfs, rdfa, xsd, skos and owl), but if we include non-W3C vocabs
too (foaf, dc, etc.), then the question becomes which ones to choose?

We could escape the entire discussion by telling toolchain authors that
it is their job to pick the vocabularies, so, for example, jQuery could
pick the following set: rdf, rdfs, xsd, foaf, dc, sioc, dbp, geo, and g.
Prototype could pick a different set of base vocabularies to initialize.

> Another thing is: What to do think about JSONing these objects,
> host them on separate documents, and import them by a function:
> 
> rdfa.importVocabulary(dc,
> 'http://www.example.org/vocabularies/json/dc.js');

I guess that would be okay as well - but seems unnecessary. We just need
a chunk of Javascript that can be executed... no need for a function
call when you can do this:

<script src="http://www.example.org/vocabularies/json/dc.js"></script>

where that script contains code like this:

rdfa.setMapping("dc", "title",
                new URI("http://purl.org/dc/terms/title"));

>> or with Mark's proposal:
>>
>> // print out all of the people names in a page
>> var people = rdfa.filterObjectsByType(foaf.Person);
>> for(i in people)
>> {
>>    var p = people[i];
>>    if(p[foaf.name])
>>    {
>>       alert("Found person named: " + p[foaf.name]);
>>    }
>> }
>>
>>   
> I like this though I had to think a time to understand it.
> It's not easy to see the triples in people. And it's hard
> to realize this construct in other programming languages.

Out of curiosity, what was difficult about it? Javascript's range
iterators are a bit different from other languages - is that what you
mean? For example, this may have been a better example:

// print out all of the people names in a page
var people = rdfa.filterObjectsByType(foaf.Person);
for(var i = 0; i < people.length; i++)
{
   var p = people[i];
   if(p[foaf.name])
   {
      alert("Found person named: " + p[foaf.name]);
   }
}

The key is that the "people" item is an array of Javascript objects -
not triples. That's what Mark's been driving at - it would be nice to
bundle the triples as higher-level objects that are easier to
manipulate. I agree with Mark. This is one way to do that.

>> We also found out that this construct is only valid in Javascript 1.6,
>> and is not implemented in the ECMA standard:
>>
>> for each ([s,p,o] in rdfa.filter(...)) { ... }
>>   
> oh, didn't they refactor it in  JS 1.7 [1] to :
> 
> for each ([s,p,o] in Iterator(rdfa.filter(...))) { ... }

Unfortunately, Javascript 1.7 is not ECMA Script 3. ECMA Script 3 does
not support destructuring assignment (or array comprehensions, which we
also talked about trying to support). Try this in the latest stable
build of Google Chrome's Javascript console:

var a = ["1", "2"];
[x, y] = a;

You will get the following error:

ReferenceError: Invalid left-hand side in assignment

However, the same code runs just fine in Firefox 2.0+. Woe for the slow
and steady lumbering of programming language standards bodies. I've been
patiently waiting for C++0x to hit for many years, now. It'll be
interesting to see which language gets 3+ fully conformant
implementations first - ECMAScript Harmony or C++0x.

Regardless - we can still design the RDFa DOM API to take advantage of
array comprehensions and destructuring assignment when they land in
browsers in the next 3-4 years. In the meantime, we'll probably be
limited to overloading Array.forEach().

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/

Received on Sunday, 18 April 2010 03:09:36 UTC