[whatwg] Trying to work out the problems solved by RDFa
chaals at opera.com
Thu Jan 1 22:12:55 PST 2009
On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell <andi at takkaria.org> wrote:
> On 2009-01-01 15:24, Toby A Inkster wrote:
>> The use cases for RDFa are pretty much the same as those for
> Right, but microformats can be used without any changes to the HTML
> language, whereas RDFa requires such changes. If they fulfill the same
> use cases, then there's not much point in adding RDFa.
>> So why RDFa and not Microformats?
(I think the question should be why RDFa is needed *as well as* µformats)
>> Firstly, RDFa provides a single unified parsing algorithm that
>> Microformats do not. ...
> This is not necessarily beneficial. If you have separate parsing
> algorithms, you can code in shortcuts for common use-cases and thus
> optimise the authoring experience.
On the other hand, you cannot parse information until you know how it is
encoded, and information encoded in RDFa can be parsed without knowing
And not only can you optimise your parsing for a given algorithm, you can
also do for a known vocabulary - or you can optimise the post-parsing
> Also, as has been pointed out before in the distributed extensibility
> debate, parsing is a very small part of doing useful things with content.
Yes. However many of the use cases that I think justify the inclusion of
RDFa are already very small on their own, and valuable when several
vocabularies are combined. So being able to do off-the-shelf parsing is
valuable, compared to working out how to parse a combination of formats
>> Secondly, as the result of having one single parsing algorithm,
>> decentralised development is possible. If I want a way of marking up my
>> iguana collection semantically, I can develop that vocabulary without
>> having to go through a central authority.
> You can develop vocabularies without going through a central authority
> already, via class or id, and many people already do.
>> Because URIs are used to
>> identify vocabulary terms, I can be sure that my vocabulary won't clash
>> with other people's vocabularies.
> Again, you can do this with class, by putting your domain name in the
> class attribute. It also depends on how much of an issue you think
> clashes will be with an iguana collection-- I would suggest that due to
> the specialised nature of the markup, clashes would be quite unlikely.
It depends how many people work on iguana collections - or Old Norse and
Anglo Saxon text, which was the use case that got me involved in the Web
in the very early 90s. It turns out that people don't, in the µformats
world, use unambiguous names, especially when they are privately
developing their own information. By contrast, those who come from an RDF
world do this by habit.
>> It can be argued that going through a
>> community to develop vocabularies is beneficial, as it allows the
>> vocabulary to be built by "many minds" - RDFa does not prevent this, it
>> just gives people alternatives to community development.
> RDFa does not give anything over what the class attribute does in terms
> of community vs individual development, so this doesn't really speak in
> RDFa's favour.
In principle no, but in real world usage the class attribute is considered
something that is primarily local, whereas RDFa is generally used by
people who have a broader outlook on the desirable permanence and
re-usability of their data.
>> Lastly, there are a lot of parsing ambiguities for many Microformats.
>> One area which is especially fraught is that of scoping. The editors of
>> many current draft Microformats would like to allow page authors to
>> embed licensing data - e.g. to say that a particular recipe for a pie is
>> licensed under a Creative Commons licence. However, it has been noted
>> that the current rel=license Microformat can not be re-used within these
>> drafts, because virtually all existing rel=license implementations will
>> just assume that the license applies to the whole page rather than just
>> part of it. RDFa has strong and unambiguous rules for scoping - a
>> license, for example, could apply to a section of the page, or one
>> particular image.
> Are there other cases where this granularity of scoping would be
> genuinely helpful? If not, it would seem better to work out a solution
> for scoping licence information...
Being able to describe accessibility of various parts of content, or point
to potential replacement content for particular use cases, benefits
enormously from such scoping (this is why people who do industrial-scale
accessibility often use RDF as their infrastructure). ARIA has already
taken the approach of looking for a special-purpose way to do this, which
significantly bloats HTML but at least allows important users to satisfy
their needs to be able t produce content with certain information included.
Government and large enterprises produce content that needs to be
maintained, and being able to include production, cataloguing, and similar
metadata directly, scoped to the document, would be helpful. As a trivial
example, it would be useful to me in working to improve the Web content we
produce at Opera to have a nice mechanism for identifying the original
source of various parts of a page.
> What would you do with scoped copyright information, anyway? I can see
> images being an issue, but ideally information about a resource should
> be kept in that resource, and as such the licence should be embedded in
> the image rather than given by a Web page. In the case of particular
> sections having particular licences, is there any practical use of
> marking up different sections with different licences over just doing
> that with text?
Mash-ups. If they have a use-case, and I think it is widely accepted that
they do, then it would seem obvious that being able to identify the source
of each part, and any conditions that vary between different sources, is a
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
More information about the whatwg