Proposal to close ISSUE-12: Benji's wishlist

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