Re: RDFa and Microformats

Hi Martin,

Before I give my detailed replies, I should just say that I absolutely
agree with your sentiment -- RDFa should be easier, and when it is, it
will help even more people than it is now.

But I think you are missing a crucial point, which is that we didn't
arrive at a situation where RDFa is better than Microformats by
accident, and now that we are in a position to build on the solid
foundation and provide some convenient shorthands, we need to plan
those carefully.


> "Squatting"  I dont know what you mean?

You could also call it 'overloading', in the sense that you are using
something and changing its meaning at the same time.

However, I prefer 'squatting', because it conveys the idea that the
use of the attribute for another purpose than its original intent only
helps the squatter.


> ... and "hacks", yes I liked to do that
> back in the 90's I think people now days call that Development ;-)

If "hacks" was a sustainable long-term development technique, we
wouldn't need well thought out solutions like RDFa.

But the reality is that we're in exactly the *opposite* situation with
Microformats; due to its weaknesses, and in particular the problems
caused by using <abbr>, you are now proposing to use a new hack.

My question is, at what point do we just agree that we're going to do
this properly, and stop going from one hack to another?


> Why is that re-creating the same problems, its just moving  data attributes
> to a machine readable area...

The Microformats community placed machine-readable data into the
@title attribute of <abbr>, and that caused problems for
accessibility. Now, if you place data into @property and @content, and
process those values outside of the normal RDFa parsing rules, you
will cause problems for RDFa parsing.

By all means try to fix Microformats -- that's none of my business.
But don't try to do so by messing up the generic RDFa parsing
algorithm.


>> If you want to use @property and @content then by all means do so, but
>> use them as defined in RDFa. In your example that would mean adding
>> @typeof.
>>
>
> There is really no need to, the @type of is the same as @class="vevent"

There really *is* a need...because @class is not part of RDFa (at
least not in the current version).

So in your example, you want the triples generated to include these two triples:

  _:a event:dtstart "2008-06-28T21:00:00" .
  _:a event:dtend "2008-06-28T21:30:00" .

I.e., you want @class="vevent" to create a new 'object', and then you
want all subsequent properties to be tied to that.

But an RDFa parser will 'see' the @property and @content values, and
tie them to the URL of the main document:

  <> event:dtstart "2008-06-28T21:00:00" .
  <> event:dtend "2008-06-28T21:30:00" .

How is the RDFa parser supposed to know that your use of @property and
@content is 'non-RDFa', and so should be ignored?


>> Otherwise, what you are effectively proposing to do amounts to
>> accepting that Microformats has run up against limitations,
>
> No not really I am saying HTML has Limitations that RDFa does not.

RDFa was intended to solve the limitations.

It's interesting that I started work on RDFa at about the same time
that the Microformats community began. At any time in the last 5 years
the Microformats community could have proposed the addition of new
attributes to play the role of @property and @content, and so solve
the <abbr> problem -- but they haven't.

I can't help thinking of the story of the little red hen.

:)


>> but then
>> imagining that it is ok to then pick and choose parts of a more
>> generic solution to try to get around the problems.
>>
>> It's a little ironic, given that we specifically went out of our way
>> to ensure that RDFa didn't conflict with Microformats.
>>
>
> It does When you are asking the users of RDFa to mark up vevents like:
>
> <div typeof="event:Vevent">
>  <h3 property="event:summary">Have I Got Old News For You</h3>
>  <p property="event:location">BBC2</p>
>  <p><span property="event:dtstart" content="2008-06-28T21:00:00">Saturday 28
> June,
>    9</span>-<span property="event:dtend"
> content="2008-06-28T21:30:00">9.30pm</p>
>  <p property="event:description">Team captains Paul Merton and Ian Hislop
>    are joined by returning guest host Jeremy Clarkson and
>    panellists Danny Baker and Germaine Greer for the
>    topical news quiz. <abbr title="in stereo">[S]</abbr></p>
> </div>
>
> http://rdfa.info/wiki/Tutorials#vEvent

That's how it is for now -- true.

But we put a lot of work into getting the fundamentals right, and now
it will be very easy to provide ways to 'default' namespaces.

Co-opting attributes without any plan, on other hand, will simply
undermine the fundamentals.


> Its just seems counter productive to me? It seems RDFa can help the wider
> community by suggesting....

Our primary goal is to help the wider community. :)

We'll do that...but we'll do it right.


> <div class="vevent">
>  <h3 class="summary">Have I Got Old News For You</h3>
>  <p class="location">BBC2</p>
>  <p><span property="dtstart" content="2008-06-28T21:00:00">Saturday 28 June,
>    9</span>-<span property="dtend" content="2008-06-28T21:30:00">9.30pm</p>
>  <p class="description">Team captains Paul Merton and Ian Hislop
>    are joined by returning guest host Jeremy Clarkson and
>    panellists Danny Baker and Germaine Greer for the
>    topical news quiz. <abbr title="in stereo">[S]</abbr></p>
> </div>
>
> ...is an example, This way you help the BBC, you help the Microformats
> Community, and you help RDFa by making it possible for authors with only a
> basic understanding of html can get to grips with RDFa.

As I said, we will provide ways to make writing RDFa easier.

But not the way you are proposing.


> Why does It have to be All or nothing? RDFa (so I am now lead to believe) is
> JUST about RDF isn't it? how a publisher extracts that information Is up to
> him?

You seem to be missing the key point, which is that Microformats has
reached an impasse because it does not have a generic parsing
algorithm. One of its strengths was that it provided small and easily
learnable formats that authors could quickly add to their documents.
But one of its weaknesses was that each of those formats could
conflict with the others.

Many people knew that this was going to be a big problem all along, so
we began with the most difficult problem first, and that is why RDFa
allows any format to be mixed with any other format.

Now, as you rightly say, we need to add the shorthands to make things
easier, but I can assure you that is a lot easier than creating a
generic syntax. :)

So it's not "all or nothing"; it's just that we will add the support
for shorthands with the same care that we created the entire RDFa
architecture.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Monday, 15 September 2008 10:16:10 UTC