Re: Proposal to close ISSUE-12: Benji's wishlist

Hi Manu,

I moved on anyway, so you may of course close issue-12.

Benji

Manu Sporny wrote:
> If there are no objections to this proposal in 14 days, we will close
> ISSUE-12: Benji's wishlist. The extra 7 days are provided to ensure that
> Benji has enough time to respond to this response.
> 
> http://www.w3.org/2010/02/rdfa/track/issues/12
> 
> Benjamin Nowack wrote:
>> So, here is my very personal view of things that I would love
>> the Semantics-in-HTML people within W3C to consider:
> 
> Benji, know that we have kept your issue (ISSUE-12) on our minds as
> we've been working on RDFa 1.1. While we were unable to make many of the
> changes that you requested, there were a few things that you had raised
> that did make it into the specification in one way or another.
> 
> Know that like you, I started out in the Microformats community and want
> to see simple solutions over complex ones. We have attempted to simplify
> RDFa such that it can be easier to use for novices. Much of this
> simplification has come from new features in RDFa such as RDFa Profiles,
> default vocabularies, the @prefix attribute and a number of other
> mechanisms that make RDFa markup more on par with Microformats and
> Microdata.
> 
> So, while we couldn't make many of the direct changes that you
> requested, we hope that you will see that the essence of what you were
> requesting has or is currently making its way into RDFa Core 1.1 and
> RDFa API 1.1.
> 
>> * align the RDFa attributes to those of Microdata and
> 
> We could not do this for two reasons:
> 
> 1. It could create a large technical and political conflict with the
>    Microdata community, possibly destabilizing both communities for
>    multiple months.
> 2. It would break backward compatibility, in a very big way, to change
>    the attribute names for RDFa.
> 
> However, the desire that you outline lives on in the design of the RDFa
> API. Specifically, the RDFa API is designed to allow both RDFa
> Processors and Microdata Processors to use the same API and storage
> mechanism. What this enables is the extraction, merging and storage of
> structured data, whether it is marked up in RDFa, Microdata, or
> Microformats. You may read more about how this is supported in the RDFa
> API document:
> 
> http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#goals
> 
> http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#data-parser
> 
>>    * disallow hidden links via @resource,
> 
> We couldn't remove @resource as an RDFa feature as it would break
> backwards compatibility with RDFa 1.0 in a way that was unacceptable to
> the RDFa WG.
> 
> However, the idea that @resource provides a "hidden link" is somewhat of
> a misnomer as it is the User Agent that determines how to expose links
> to the person browsing.
> 
> For example, if a foaf:Person's hompage is expressed using foaf:homepage
> using @resource as the hyperlink target, the User Agent could find their
> foaf:name and visually express that clicking on the person's name will
> take you to the person's home page.
> 
> Whether or not a link is exposed in a User Agent UI is not the purview
> of the RDFa WG and we hope that browser manufacturers or other User
> Agents and Javascript developers will provide many ways of following
> links expressed via @href, @src and @resource.
> 
>>    * move from ugly to ugly-but-consistent attribute names ;)
> 
> Again, we could add attribute names, but removing attribute names was
> not listed in our charter as a possible work item and was a non-starter
> for the RDFa WG membership.
> 
> Adding duplicate attributes was frowned upon by the RDFa WG - as having
> duplicate attributes that performed the same thing would create author
> confusion. A great deal of time went into picking the attribute names
> the first time around, most have learned to live with the attribute
> names, other people hate them. I do agree that Microdata's names are
> more consistent. What we picked for RDFa 1.0, for better or for worse,
> is what we're stuck with for the foreseeable future.
> 
> Removing attributes would have broken many RDFa 1.0 documents, and the
> RDFa WG's charter focused on ensuring backwards-compatibility.
> 
> It is for these two reasons that we can't move "from ugly to
> ugly-but-consistent attribute names". The trade-offs were too great to
> make this move.
> 
> That said, we did introduce @prefix to replace @xmlns - as there was a
> great deal of push-back on @xmlns. The technical challenges for @xmlns
> have been addressed in the HTML+RDFa spec being proposed via the HTML
> WG. However, we are proposing that authors shift to using @prefix to
> provide CURIE mappings as it doesn't confuse namespaces with prefixes.
> 
> So, we did make this one change that is in the spirit of what you
> outline above.
> 
>> * make resource description boundaries explicit
> 
> The RDFa WG feels that the resource description boundaries are already
> explicit:
> 
> 1. If there is no @about specified, the in-scope subject is the
>    current document.
> 2. Using @about, @src, @href and @resource changes the in-scope
>    subject.
> 
> We do realize that RDFa chaining creates a number of confusing issues
> for beginning authors, however, removing chaining from RDFa 1.1 was a
> non-starter for the RDFa WG for the following reasons:
> 
> 1. It would be a backwards-incompatible change.
> 2. RDFa chaining is a powerful tool that reduces RDFa markup and
>    also enables authors and HTML template engines to express concepts
>    more compactly.
> 
> So, we believe that this is already being done as much as possible. Any
> further changes would break backwards compatibility in a bad way.
> 
>> * disallow CURIEs or similar indirection mechanisms that are
>>   tricky in publishing systems based on nested templates and which
>>   make JavaScript access more complicated than necessary.
> 
> Disallowing CURIEs would introduce a backwards-incompatible change to
> RDFa 1.1 and was a non-starter as it would make all RDFa 1.0 documents
> invalid per RDFa 1.1.
> 
> We did, however, introduce several new concepts in RDFa 1.1 to attempt
> to address the concern that you raise. These features are:
> 
> 1. RDFa Profiles:
>    http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#s_profiles
> 2. The @vocab attribute:
>    http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#dfn-vocab
> 3. RDFa Terms (via RDFa Profiles):
>    http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#s_terms
> 4. RDFa Default Profile:
>    http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#hostlangconf
> 
> The hope is that the small subset of publishing systems that use nested
> templates and do not have the ability to pass along state information
> into the templates can opt to use one or more of the alternative
> mechanisms above in order to express the RDFa document in a way that is
> generates more compact code than RDFa 1.0
> 
> We have also introduced an RDFa API in order to make processing via
> Javascript less complicated than it was in the past:
> 
> http://www.w3.org/2010/02/rdfa/sources/rdfa-api/
> 
>> * turn RDFa into a syntactic superset of Microdata.
> 
> RDFa 1.1 is designed to be a complete superset of Microdata. Anything
> that you can do in Microdata, to our knowledge, you can do in RDFa.
> 
> Making it a syntactic super-set, however, would have been difficult due
> to political issues between WHAT WG, HTML WG and RDFa WG. However, as I
> explained above, via the RDFa API - one can integrate structured data
> from Microdata markup, Microformats markup and RDFa markup into a single
> data model and manipulate that data via the RDFa API.
> 
> So, while we didn't make RDFa a syntactic superset, we did make it a
> functional superset and created a mechanism (the RDFa API) to meld the
> Microformats, Microdata and RDFa worlds together.
> 
>> * maybe: reduce the HTML part of Microdata to Model, Syntax,
>>   and DOM API, let the relevant RDF group contribute to an RDF 
>>   mapping.
> 
> So, we did this, but perhaps not in the way that you were proposing.
> There is now a unifying model for Microformats, Microdata and RDFa -
> that is, RDF. The syntaxes stay the same - Microformats, Microdata and
> RDFa. The DOM API is the RDFa API - which is a bit of a misnomer,
> because it can handle Microformats, Microdata and RDFa just fine.
> 
> The RDFa API is also designed to have pluggable storage models, so if
> RDF is not your thing, you can implement a different storage model
> (key-value, quadstore, etc.):
> 
> http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#data-store
> 
> The same goes for querying - the RDFa API supports pluggable query
> models. So, one can query the storage using JSON objects, SPARQL, SQL,
> or whatever other mechanism one deems fit for querying structured data
> in a web page.
> 
>> * a consistent vocabulary/itemtype approach for Microdata
>>   (via XMDP, RDF Schema, or somesuch), possibly with a set
>>   of pre-defined vocabs/types like vcard, cal, or dc stuff.
> 
> I'm assuming that this statement was addressed to Ian Hickson, editor of
> the Microdata specification, since he was cc'ed on the original e-mail?
> 
> That said, as I outlined above, we have a consistent story for
> pre-defining prefixes and terms in RDFa 1.1 now - RDFa Profiles. We hope
> that this eases markup for many authors that are new to Linked Data and
> the semantic web. We also hope that it makes transition from
> Microformats to a more solid linked data foundation easier for those
> that are familiar with using Microformats in their websites.
> 
>> * buy my new single!
> 
> ARC2 FTW!
> 
> http://arc.semsol.org/download
> 
>> I know, I'm asking too much.
> 
> We tried our best to address the issues that you had. Please let us know
> how we did.
> 
>> Fallback list:
>> * accept that there are different needs, which - as sad as it
>>   may be - require two different solutions (with poor me 
>>   somewhere in between).
> 
> We hope that we've been able to close the gap between the two solutions.
> As stated previously in this e-mail:
> 
> 1. RDFa 1.1 is now a complete superset of Microdata.
> 2. RDFa 1.1 markup is now easier thanks to RDFa Profiles.
> 3. The RDFa API attempts to create a single API for working with
>    Microformats, Microdata and RDFa.
> 
> All of these changes were influenced by community feedback, including
> yours, and we hope that we have addressed the things that we could
> address while ensuring backward-compatibility (where it counted) for
> RDFa 1.0.
> 
> This resolves ISSUE-12, please comment in 14 days from this post if you
> object to this answer. If there are no objections within 14 days,
> ISSUE-12 will be closed.
> 
> -- manu
>

Received on Monday, 6 September 2010 08:03:55 UTC