A new approach to accomplishing RDFa Profiles

Hi all,

During the telecon today, it seemed as if were settling on two basic
techniques to provide RDFa Profiles to beginning web authors. The first
is the name/value based approach (@token/@prefix/@map/etc.), the second
is the RDF Vocabulary term approach
(rdfa:prefix/rdfa:keyword/rdfa:alias/etc.).

The underlying concern is that we might not get either solution into the
FPWD at the rate that we're progressing. We're making progress, but the
path forward is still not clear... and that is putting the FPWDs at risk.

We could probably spend many telecons discussing the merits and
drawbacks of each approach, and while that would be helpful, it may be
more helpful to accept both approaches as viable paths forward and spec
both of them for now. The understanding would be that we may strip one
or both features out of the spec before Last Call.

The goal in spec'ing both features and placing it into the FPWD
documents is to get wider feedback from the general web authoring
community. Once spec'ed, we could go to Google, Yahoo, Dublin Core, FOAF
and other vocabulary providers and ask them which approach they would
prefer (one, both, or neither).

For those that are not aware of W3C publishing practices, there doesn't
need to be consensus for FPWD documents. It is suggested that we release
early and revise often based on external feedback. Spec'ing both
approaches would be one way of getting that external feedback.

If we do this, we should also clearly mark that they are experimental
and that the Working Group is soliciting the greater web community for
feedback on both approaches for accomplishing RDFa Profiles.

This approach ensures that we move forward on the FPWDs and don't become
deadlocked in trying to find the "right" solution this early in the
process. Thoughts/comments?

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

Received on Thursday, 18 March 2010 16:38:26 UTC