Re: A new approach to accomplishing RDFa Profiles

Manu,

I am not against doing this, but I am really lost with the many terms an
attribute names we use ourselves, and I am not sure what we are talking
about any more. (Sorry I could not be the meeting yesterday...). We are
having now a plethora of things around @token, @profile, @map, @vocab,
... and I am lost what is what!

I try to summarize what are the stuffs we have, to see if we could at
least agree on the terms to help our discussions...


1. we have a proposal to allow @xmlns to define not only prefixes by
directly keywords (I think that is what Mark is proposing). Ie, @xmlns
would be a generic mechanism to define, possibly, full URIs)

2. we have/had a discussion to provide an alternative to the @xmlns
syntax. The information is still local to the file, and the semantics is
the same as @xmlns (including the addition above)

3. we had a proposal to use a separate attribute to provide a 'default'
prefix for an xml subtree that could be used for keyword mapping. There
were discussions whether we should reuse @typeof or use a separate attribute

4. we have proposals to refer to an external document, that defines
keywords and, possibly, prefix mappings. There were discussions whether
that document should define prefixes in the first place and, if yes,
whether prefix definition should be separated from keyword definitions;
there were discussions whether the definition should use some RDF
vocabulary or whether we would introduce a new (albeit simple) syntax to
do so in the included documents.

So I am not sure when you refer to 'two basic techniques', which one you
refer to...

/me is lost:-(

Ivan



On 2010-3-18 12:37 , Manu Sporny wrote:
> 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
> 

-- 

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
vCard  : http://www.ivan-herman.net/HermanIvan.vcf