Re: Quick review of RDFa DOM API?
On 05/05/10 09:05, Robin Berjon wrote: Hi Manu, Just a very quick review. Thanks Robin - preliminary (non-official) feedback below. At a high-level, all of your points are fair points and will influence the path forward. Since I sent out the call for reviews, Mark Birbeck has come up with a secondary proposal for the RDFa DOM API: http://code.google.com/p/backplanejs/wiki/RdfaDomApi We're currently attempting to merge both proposals by specifying a high-level and low-level API for accessing data in a document. We have been having an intense, healthy discussion about these things over the past several weeks: http://www.w3.org/2010/02/rdfa/meetings/2010-04-29 http://www.w3.org/2010/02/rdfa/meetings/2010-05-06 Specifics, below: - Why would anyone want to capture PlainLiteral values in a specific encoding? Since the value is provided as a DOMString, it should just be that — a string, with any original encoding information forgotten. Otherwise, you should use a binary type to capture the value (maybe a Blob) but I really don't see why. The short answer is that we didn't know if there were any issues when placing content encoded in say, Cyrillic ISO-8859-5 into a DOMString. If this WG doesn't see any problem with forgetting the original encoding information, then we'll drop any requirement to remember the original encoding information. - element points to the first node in the DOM tree that is associated with this PlainLiteral. I'm not sure what that means. We will try to make this more clear in the FPWD. A Plain Literal could be generated when one does something like this: div property=bar datatype=spanFoo/span spanBaz/span /div There are multiple DOM Nodes that are associated with the plain literal, but we want to convey that the element that will be associated with the PlainLiteral will be the div element... not the first span element. - language is said to be a two character language string as defined in [BCP47]. BCP47 has language codes that have more than two letters. That's a mistake, both XHTML 1.1 (Second edition - yet to be published) and HTML5 say that any language code in BCP47 is valid. Also, if the source language is not BCP47 conformant, is it exposed? RDFa listens to whatever is in the @lang or @xml:lang attribute - in other words, it heeds what is exposed via the Host Language. So yes, values that are not BCP47 are exposed, but are not valid. - I'm not sure that I fully grasp the full value of the IRI interface. When TypedLiteral's type field returns an IRI, what is the IRI's element? We wanted to provide types that people could use when writing Web Applications in Javascript using the RDFa DOM API. There are places where you need to be exact about what you're passing the API, for instance... when specifying an object, you could pass in a PlainLiteral, a TypedLiteral, a Blank Node or an IRI. For example: // this is something we may do in the FPWD, not in there yet var people = rdfa.getDataByObject(new IRI(http://example.org/#robin;)); The code about would get all people in the data set that refer to your IRI in some way foaf:knows, geneology:parentOf, fb:likes, etc. We are working on a mechanism that would allow people to just do this (by assuming anything with scheme://... is a IRI): var people = rdfa.getDataByObject(http://example.org/#robin;); ... but even then, there are some cases where what you want isn't an IRI, but a PlainLiteral (Facebook's OGP, for example), or vice versa. So, you may have to do this in some cases: The Facebook Open Graph Protocol markup for Rotten Tomatoes: meta property=og:url content=http://www.rottentomatoes.com/m/1194522-how_to_train_your_dragon/; / The code: var dragon = rdfa.getDataByObject(new PlainLiteral(http://www.rottentomatoes.com/m/1194522-how_to_train_your_dragon/;)); The code above would get all items that mention the URL to How to Train Your Dragon on Rotten Tomatoes as a PlainLiteral. The IRI's element would be whatever element specified @datatype, or the element that encapsulates the value of the TypedLiteral. - xsd:DataTime typo? Yes, typo - thanks. - Any valueOf (); isn't it any? (It's not clear in WebIDL) The type name is Any. http://dev.w3.org/2006/webapi/WebIDL/#idl-any - JS doesn't have a DateTime object, just a Date. Thanks, will fix that in the next rev. - Constructing a triple seems painful: var trip = new RDFTriple(new IRI(http://foo...;), new IRI(http://bar...;), new IRI(http://dahut...;)); Yes, and the hope is that most developers will never need to construct a triple. It's a big point of pain in the current RDFa DOM API. We think that in the next revision, most of the types will only be useful to advanced developers. Another way to put it is that we think that for most of the use cases, nobody will have to worry about types. However, there are some cases where you do want to worry about types and that is why we expose the types for IRI,
Re: Quick review of RDFa DOM API?
Hi Manu, Thanks for your e-mail (and the succinct list of relevant questions). All - can anyone in the WebApps WG/Community commit to a quick high- level review of the RDFa DOM API draft? Manu - FYI, we've got a significant number of specs in progress [1] so I don't think you should block on our review. -Art Barstow [1] http://www.w3.org/2008/webapps/wiki/PubStatus On May 1, 2010, at 2:03 AM, ext Manu Sporny wrote: Hi folks, This is a call to see if anyone from this WG can do a quick high-level review of the RDFa DOM API. We are planning a FPWD in a week or two and would like to see if what we have so far is a good start, makes sense to those unfamiliar with RDF/RDFa, and what improvements we should make in the coming months to make the API useful for developers. The latest (FPWD-ready) document is here: http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-dom-api-20100429/ We don't need a thorough technical review - just a quick look through to see if this is an API you could see yourself using, or if you would prefer something else. We're mostly interested in having the following questions answered (answer as few or as many as you'd like): * Is the purpose of the RDFa DOM API clear? * Is it clear how one would extract data about a particular subject? * Is it clear how one could extract data about a certain property? * Does the document makes sense to someone that only has a passing knowledge of RDF and RDFa? * Should we eschew RDF concepts entirely and just return dumb associative-arrays? No classes, just associative arrays. * Should we integrate a query language, like SPARQL, or leave that to an add-on library that could use the RDFa DOM API as the basis for that implementation? * Should the rdfa library go in the global scope, or on document.rdfa, or something else like document.meta? * Would you rather see the API implemented on document and element objects rather than in an rdfa object? Something like element.filterData(); * Is the IRI mapping mechanism a design pattern that developers are comfortable with using? * Should we use more markup/example combinations, or are the current markup-less examples helpful? -- 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/
Re: Quick review of RDFa DOM API?
Hi Manu,
On May 1, 2010, at 08:03 , Manu Sporny wrote:
This is a call to see if anyone from this WG can do a quick high-level
review of the RDFa DOM API. We are planning a FPWD in a week or two and
would like to see if what we have so far is a good start, makes sense to
those unfamiliar with RDF/RDFa, and what improvements we should make in
the coming months to make the API useful for developers. The latest
(FPWD-ready) document is here:
http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-dom-api-20100429/
Just a very quick review.
- Why would anyone want to capture PlainLiteral values in a specific
encoding? Since the value is provided as a DOMString, it should just be that —
a string, with any original encoding information forgotten. Otherwise, you
should use a binary type to capture the value (maybe a Blob) but I really don't
see why.
- element points to the first node in the DOM tree that is associated with
this PlainLiteral. I'm not sure what that means.
- language is said to be a two character language string as defined in
[BCP47]. BCP47 has language codes that have more than two letters. Also, if
the source language is not BCP47 conformant, is it exposed?
- I'm not sure that I fully grasp the full value of the IRI interface. When
TypedLiteral's type field returns an IRI, what is the IRI's element?
- xsd:DataTime typo?
- Any valueOf (); isn't it any? (It's not clear in WebIDL)
- JS doesn't have a DateTime object, just a Date.
- Constructing a triple seems painful:
var trip = new RDFTriple(new IRI(http://foo...;), new
IRI(http://bar...;), new IRI(http://dahut...;));
I can see why from the draft, but shortcuts would help. Or maybe it's a library
thing.
- forEach: you can either define it as receiving just Function so that it
gets a function. That's fine, but it doesn't tell you what that function is
called with. The other option is to have it receive a FooCallback object, which
is in turn defined as an interface with a single method that has the signature
you expect, and has [FunctionOnly, NoInterfaceObject].
- any reason why RDFTripleList wouldn't stringify to a list of RDFTriples?
- VERSION. Don't. API versioning doesn't work, in fact it doesn't exist.
- I'm not sure that I understand the value of the Convenient IRI Mapping.
The intent that I understand is to have:
rdfa.foo.bar # http://foo.com/ns#bar
rdfa.dahut.hunting # http://dahutsgalore.org/vocabularies/hunting
rdfa.dahut.unicorns # http://w3.org/2009/dap
It seems that the proposed solution is that you must first:
rdfa.setMapping(foo, bar, http://foo.com/ns#bar;);
rdfa.setMapping(dahut, hunting,
http://dahutsgalore.org/vocabularies/hunting;);
rdfa.setMapping(dahut, unicorns, http://w3.org/2009/dap;);
What's the added value over:
var myMap = { foo: { bar: http://foo.com/ns#bar; },
dahut: { hunting:
http://dahutsgalore.org/vocabularies/hunting;,
unicorns: http://w3.org/2009/dap; }};
?
--
Robin Berjon - http://berjon.com/
