Re: New RDF API and RDFa API Editor's Drafts

Hi Ivan,

As you say, we'll go through it on the call. But the rationale is that
an implementer should not have to implement the full RDF API, just to
allow their users access to the RDFa in a document.

For example, a browser vendor may choose to implement the RDFa API to
provide a simple way to retrieve triples, and they would therefore
expose:

  document.data

However, if they also decided to allow access to RDF-world proper --
with its triples, literals, data typing and so on -- they can still
add the RDF API, and expose it like this:

  document.rdf

or perhaps this:

  document.data.rdf

(See section 3.3.1.)

We felt this was a good way to address a number of seemingly
conflicting desires:

1. To keep the features needed for programmers in a browser
environment as simple as possible, and to hide RDF from them until
they are ready for it.

2. To expose the full power of RDF to those that do want it, and to
allow people working on libraries that are outside of a DOM
environment to pursue standardisation.

3. To enable the two specs to move at different paces if necessary,
without holding each other up.

4. To allow different audiences to get the most out of the specs that
are of most relevance to them.

I think these drafts are going a long way to meet these goals.

Regards,

Mark

On Thu, Dec 9, 2010 at 10:46 AM, Ivan Herman <ivan@w3.org> wrote:
> Wow. :-)
>
> This is not a detailed set of comments, just some questions while reading the document...
>
> - PrefixMap has an importFromGraph, but I do not see, in the Graph object, any association with a PrefixMap. Isn't that missing? (same with terms and profiles)
> - I am not sure I see how the two document bind among one another. The RDFa API seems to be, at this moment, completely independent of the RDF API, there is no notion of triples, blank nodes, etc. It looks as if that API would deliberately hide all RDF-ness of the data. I can see that for some constituency this is fine, but for some it may not (or do we say that the RDF API has a parser and that is what one would use?). On the other hand, the propery group seems to be a notion that may have its use for an RDF API, too...
>
> I guess you will have to make a presentation this afternoon!
>
> Cheers
>
> Ivan
>
>
>
> On Dec 9, 2010, at 06:59 , Manu Sporny wrote:
>
>> Hey folks,
>>
>> As we had discussed last week[1], Nathan, Mark and I met over the
>> weekend and have been in steady contact throughout the week as we worked
>> through splitting the RDFa API specification into two separate
>> documents. We've probably put in close to 30 hours of work since Sunday
>> getting the two documents separated and figuring out most of the
>> difficult design decisions.
>>
>> The first document is the RDF API specification, which is a set of
>> low-level interfaces for working with RDF data. The second is the RDFa
>> API specification, which is a high-level interface for working with RDFa
>> data in web pages in an easy-to-use, language-native format.
>>
>> The two may work in concert, but we have carefully separated them such
>> that the RDFa API can stand on its own if needed. This means that both
>> specs are decoupled and can proceed to REC independently, which is a
>> good thing. Most of the really nasty design issues have been resolved,
>> but there are many more minor ones lurking throughout the specs.
>>
>> All three of us are fairly happy with the direction and think that the
>> documents are in a state that the Working Group could use to evaluate
>> the current direction. Keep in mind that both documents are far from
>> perfect, very very pre-alpha - the prose is just plain wrong in most
>> places.
>>
>> The interfaces are not as volatile as they have been over the past week
>> - so if you look at anything, look at the WebIDL.
>>
>> The RDF API
>> http://www.w3.org/2010/02/rdfa/sources/rdf-api/
>>
>> The RDFa API
>> http://www.w3.org/2010/02/rdfa/sources/rdfa-api/
>>
>> We'll go through each document tomorrow.
>>
>> -- manu
>>
>> PS: Mark - the registerQueryFactory/registerParserFactory/etc. stuff is
>> not there. Nathan and I were able to come up with some very good reasons
>> we should think about avoiding that approach. However, that doesn't mean
>> that we may not put them back in the future. I think this may be the
>> biggest thing that the three of us may disagree on at the moment.
>>
>> [1] http://www.w3.org/2010/02/rdfa/meetings/2010-12-02
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny)
>> President/CEO - Digital Bazaar, Inc.
>> blog: Linked Data in JSON
>> http://digitalbazaar.com/2010/10/30/json-ld/
>>
>
>
> ----
> 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
>
>
>
>
>
>

Received on Thursday, 9 December 2010 12:39:46 UTC