[whatwg] Trying to work out the problems solved by RDFa
julian.reschke at gmx.de
Sat Jan 3 05:02:50 PST 2009
Tab Atkins Jr. wrote:
>> 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.
With RDFa, most of the parsing is done by HTML. So I would call it an
"RDFa processor". And yes, that doesn't change the fact that code needs
to be written. But it affects the type of the code that needs to be written.
> 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 ^_^).
Well, there are lots of conditionals in this statement :-)
> 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.
I would say this is because the research and design in this area totally
predates HTML5. Are you seriously suggesting that all of that needs to
start from scratch?
>>> 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.
- Microformats: how do they solve sharing RDF data?
- embedded data in <script>: see discussion above
- embedded XML: embedded in where?
- custom attributes: wow, that sounds like RDFa
- @class and friends: that sounds like eRDF, which the way it is
currently specified is broken in HTML5 (@profile)
- natural language: hey great, please elaborate :-)
>> My understanding was that RDFa has been produced in order to address
>> problems with other approaches, such as using <meta> elements, eRDF, or
>> 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.
That's what you and Ian claim. Many disagree.
> 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
The very existence of Microformats prove that people want to augment
their content with metadata that is machine-readable. Some of the
shortcomings of Microformats are caused by the way they are retrofitted
into HTML. So it's totally natural to discuss whether a better solution
can be reached by adding new stuff to the language.
>> 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."
> As a note, this isn't the W3C's HTML WG. The WHATWG is independent
> from the W3C.
Sounds like we need to restart the thread on the HTML WG's mailing list
Best regards, Julian
More information about the whatwg