[whatwg] Trying to work out the problems solved by RDFa

[Tab Atkins Jr.]

On Fri, Jan 2, 2009 at 11:55 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> Tab Atkins Jr. wrote:
>>
>> ...
>> Solutions for this already exist; embedded N3 in a <script> tag, just
>> to name something that Ian already mentioned, allows you to mash RDF
>> data into a page in a machine-extractable way, and brings in any of
>> the specific ancillary benefits of RDF.
>> ...
>
> Well, it'll require an N3 parser where previously none was needed.

RDFa requires an RDFa parser as well, and in general *any* metadata
requires a parser, so this point is moot.  The only metadata that
doesn't require a parser is no metadata at all.

> Also, it
> separates the metadata from the text, a situation most people want to avoid.

That sounds like a requirement, but it's one that already presumes
that metadata is useful to embed in webpages.  It has not yet been
established that there is a problem worth solving that metadata would
address at all.  (Clarifying this was the primary purpose of Ian's
mail, and my first mail in this thread.)

> This may work, but as far as I can tell, the use of <script> for "data
> blocks" is an afterthought -- for instance, it's described in a section
> about, well, Scripting.
>
> So, is anybody using this successfully in practice?

I have no idea.  The point is, though, that it *is* an existing
possibility that requires no further effort from this working group or
browser developers.  As such, if it solves the problem (whatever it
is, since that hasn't yet been well-established) sufficiently, we can
leave it alone.  It is in the best interests of everybody if a
solution can be found without any changes to the language, because it
means browser uptake is quick (immediate and retroactive, to be
precise ^_^).

We have to ensure that the problem isn't already solved by the
language first, and only after that can we evaluate whether the
language is the correct place to solve the problem, and only after
*that* can we start discussing how to actually go about solving the
problem in the language.  Too much of this discussion is jumping
straight to step 3, so Ian, I, and others are trying to focus it on
step 1.

>> ...
>> Not quite correct.  Again, the problem of embedded shareable data in a
>> web page has been solved multiple times.  The specific problem of
>> sharing *RDF* data (due to needing/wanting the specific benefits RDF
>> can offer) has also been solved.  What are the precise problems that
>> require *RDFa* as a solution?
>> ...
>
> Could you elaborate a bit on these solutions?

Microformats, embedded data in <script> blocks, embedded XML, custom
attributes, other miscellaneous uses of @class and related attributes,
and simply putting the data in natural language.

These solutions already exist, and in several cases are easier to use
than RDFa.  Do they have specific failings that RDFa addresses?  Are
these failings significant enough to warrant extending the language to
solve them?  To we *understand* the failings (assuming they exist and
are significant) well enough to be confident we can solve them
correctly in the language, rather than waiting for the community to
solve them themselves and then simply reifying their solutions?

> My understanding was that RDFa has been produced in order to address
> problems with other approaches, such as using <meta> elements, eRDF, or
> microformats.
>
> If there is a *successful* alternative to RDFa that does not require new
> attributes, please let us know :-).

The most successful alternative is nothing at all.  ^_^  We can
extract copious data from web pages reliably without metadata, either
using our human senses (in personal use) or natural-language-based
processing (in search engine use).  It has not yet been established
that sufficient and significant enough problems *exist* to justify a
solution, let alone one that requires an addition to html.  That is
what Ian is specifically looking for.

Unfortunately, you really do need to justify metadata anew; you can't
just point at Microformats or something similar and say "we're doing
the same things as those guys!".  They exist currently because they
can fit their solutions into the language as it is; there is no
further need to justify them in this group.  Modifying the language,
though, is an explicit admission that this is a problem worth solving
and worth solving in a particular way, and so requires significant
justification.

>> ...
>> Well, there are many things that would offer more advantages than
>> disadvantages by themselves.  We can't possibly include all of them in
>> the spec; you can think about this as including a hidden large
>> disadvantage of 'will grow the size of the spec and the amount of work
>> implementors have to do'.  Thus the advantages must generally be
>> significantly larger than the disadvantages; this is why the best
>> argument for including something in the spec is often "there are
>> already widespread hacks to accomplish this".  <video>, for example,
>> was included based on pretty much precisely that argument.
>> ...
>
> Reminder: RDFa is one of the things the (W3C) Working Group's Charter
> mentions as candidate for inclusion (either by a generic extensibility
> mechanism, or otherwise by extending the language):
>
> "The HTML WG is encouraged to provide a mechanism to permit independently
> developed vocabularies such as Internationalization Tag Set (ITS), Ruby, and
> RDFa to be mixed into HTML documents."
> <http://www.w3.org/2007/03/HTML-WG-charter.html#other>

As a note, this isn't the W3C's HTML WG.  The WHATWG is independent
from the W3C.

~TJ