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:

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:

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=""><span>Foo</span> <span>Baz</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(""));

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("");

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

The code:

var dragon = rdfa.getDataByObject(new

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

>   - 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, PlainLiteral, BlankNode, and TypedLiteral.

> I can see why from the draft, but shortcuts would help. Or maybe it's
> a library thing.

We hope to provide common shortcuts... we're actively working on
determining what those shortcuts should be.

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

You are right, we need to define that more clearly. Will do so in the
next rev.

>   - any reason why RDFTripleList wouldn't stringify to a list of
> RDFTriples?

No reason. What we're grappling with is what the format of the list
should be. N3 or TURTLE? Or should it be a read-able string for developers?

>   - VERSION. Don't. API versioning doesn't work, in fact it doesn't
> exist.

We'll strip this out of the next version of the RDFa DOM API.

>   - I'm not sure that I understand the value of the "Convenient IRI
>     Mapping". The intent that I understand is to have:
> #
>     rdfa.dahut.hunting #
>     rdfa.dahut.unicorns #
> It seems that the proposed solution is that you must first:
>     rdfa.setMapping("foo", "bar", "");
>     rdfa.setMapping("dahut", "hunting", "
> /vocabularies/hunting");
>     rdfa.setMapping("dahut", "unicorns", "");
> What's the added value over:
>    var myMap = { foo:   { bar: "" },
>                  dahut: { hunting: "
> /vocabularies/hunting",
>                           unicorns: "" }};
> ?

Short answer - your solution is better (as long as developers aren't
required to type all of that out). We've come up with one that's better

// This is really all you need
rdfa.setMapping("foo", "");

Then doing something like this:

would automagically result in this:


The getter for the "foo" IRI Mapping object would automatically append
any value attempted for retrieval by the getter to the end of the base
IRI and return that. So in this case, the base IRI is
"" and the getter asked for the "bar" property, thus
the final IRI is: ""

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP

Received on Monday, 10 May 2010 16:34:04 UTC