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

On Apr 18, 2010, at 05:09 , Manu Sporny wrote:

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

That is a very dangerous path to go imho. If we fix the mappings to any list, then we will have a maintenance problem (this is the same discussion as what we may have if we decide to have some default profiles...). You list the standard W3C vocabularies; what if in 2 years there is a new vocabulary standardized by W3C?

I very much see the point of using rdfa.xsd.integer or rdfa.rdf.type instead of, say, RDF["type"], but I am not sure it is realistic to do that in general. Specific implementations may be able to do that (ie, I think it would be possible to do a dynamic assignment of attributes in Python) but if Javascript cannot handle that (which I do not know) than we may have to live with the uglier but more flexible approach...


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

Which is nice but would leave us with interoperability issues nevertheless... as an author I would not trust implementation to do it, so I will use xsd["integer"]...

Ivan


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


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf