- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 02 Sep 2010 12:34:26 -0400
- To: RDFa WG <public-rdfa-wg@w3.org>, Benjamin Nowack <bnowack@semsol.com>
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 -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: WebID - Universal Login for the Web http://blog.digitalbazaar.com/2010/08/07/webid/2/
Received on Thursday, 2 September 2010 16:34:57 UTC