W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > June 2010

Re: Potentials of the RDFa DOM API

From: Niklas Lindström <lindstream@gmail.com>
Date: Fri, 11 Jun 2010 03:03:44 +0700
Message-ID: <AANLkTikPTJ97HrHinxL-d1qQUB4EhYWPXMoPRLD9isEC@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: public-rdfa-wg@w3.org
Hi Manu, all!

First of all, congrats to the progress to FPWD!

2010/5/25 Manu Sporny <msporny@digitalbazaar.com>:
> Hi Niklas,
> Yes, I think there is much that the RDFa Community can collaborate on
> with you regarding the RDFa DOM API.
> On 05/22/2010 08:05 AM, Niklas Lindström wrote:
>> 1. Do you see the same potential as I do of a general API?
> Yes, definitely.
>> 2. Is it feasible to extract these non-DOM-intrinsic parts from the
> Yes. That said, we need to be very careful as we're chartered to create
> an RDFa DOM API and we must stay focused on doing that. If, as a
> side-effect, we create something that is easy to lift into another
> specification - great.

Indeed, I definitely understand and agree that a general RDF API is
beyond the scope of this group.

My main idea is just that since there are a bunch of API:s for
object-oriented languages, it would be very nice if the basis of the
RDFa DOM API was as isomorphic to their general, common design as
possible. I think this can be done without too much effort, since they
share a very explicit foundation (RDF itself) and often look very
similar to each other (as do the RDFa DOM API, I assume by design).
Perhaps it is possible in plain text to demarkate what this general
core model is. While the current design has pretty clear connections
to the DOM (via e.g. 'origin'), these seem to be easy to call out as
being specific for RDFa within a DOM (and perhaps possible to connect
with the quad concept of source context(s)).

I know this general thinking isn't so helpful though, so I'll go
through the document in detail and see if I can come up with proper,
substantial suggestions. (I'm travelling in Cambodia this month, so
I'm rarely online.)

>> 2. Would it make sense to create a Working Group for such an API,
>> decoupled from RDFa?
> Perhaps... but again, it's a very long road to creating a Working Group
> at the W3C. This may be a part of the RDF Next Steps workshop that is
> going to be happening this summer.

I certainly understand this. Let's see what happens there.

>> Finally, will anybody working with the RDFa DOM API participate in the
>> RDF Next Steps workshop [7]?
> Ivan is going to be there, I think.

Ah, of course. I knew that. :)

> How would you like to proceed, Niklas?
> You could start by giving us a review on the RDFa DOM API (after we do a
> FPWD in the coming weeks). For example, you could let us know your take
> on what could be split out. Or, provide an implementation in another
> language to see how many of the concepts carry over to another language.

I'll look into that. Since I tinker with a couple of RDF utility API:s
in both Python, Java and Javascript, I think I can use this API as a
focus for (some of) those.

I have two specific things I'd like to mention right away:

1. The Property Group. I find it to be a good piece of
utility-oriented design. And I like that it (like much of this API) is
basically string-oriented.

But since the 'get' method returns a list of anything, that may lead
to a lot of tinkering to get at specific values from rich data
(checking for size > 0, for type, the need to do a 'get' for each
IRI/BNode encountered to get a new property group, etc).

One suggestion I have is to extend the Property Group concept to
support a couple of utility methods, based on the RDFa attributes

    Get one (the first) single literal value for the predicate (or null)
    Get all literal values for the predicate
    get a Property Group for one (the first) IRI/BNode value for the
predicate (or null)
    get a Property Group for each IRI/BNode value for the predicate

And also getRev/getRevs for "incoming" relations.

This is how I designed the "Description" utility [1]. I believe this
design could fit the RDFa DOM API as well. (It also has add*-methods
for this, which may or may not be a good fit for this API.)

2. I'm a bit unsure about the name "Property Group". How about calling
it e.g. Description, DataItem, or similar? Since, as I understand it,
it's an object representing data for a singular subject, not just a
"group of properties", right?

That's all for now.

Best regards,

[1]: http://pastebin.com/Zs4LK0m0
Received on Thursday, 10 June 2010 20:04:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:47 UTC