[uf-discuss] Microformat tools bogosity test
danny.ayers at gmail.com
Wed Mar 7 01:51:35 PST 2007
On 06/03/07, Scott Reynen <scott at randomchaos.com> wrote:
> On Mar 6, 2007, at 10:09 AM, Kevin Marks wrote:
> > Let me clarify that - Danny's 'ceci n'est pas une pipe' example is
> > clearly not 80%.
> I think 80% is irrelevant here because it's not even the same
> problem. Profile URIs solve the problem of ambiguous assertions.
> They do not solve the problem of false assertions. It doesn't matter
> whether or not false assertions is an "80%" problem. Profile URIs
> simply don't solve that problem.
This is the kind of unfocused
> discussion we can easily avoid by starting with the *problem* rather
> than the solution, i.e. following the process:
> We seem to be at the "iterate" stage now with the ambiguity problem,
There I disagree - as far as the theory goes, for microformats the
problem is effectively solved.
The notion of profile URIs has gone through the community process, and
there's even a microformat to support them: XMDP. It's been accepted
that each microformat should have a profile URI .
The remaining problem is that it's not possible to both follow good
practice in regard to web architecture *and* respect the convention
side of microformats. If I want to use a profile URI for hReview my
only option right now is to make up one of my own. This is legitimate
in terms of web architecture, but may lead to mutliple equivalent
profiles making the tool developer's job that much harder.
Just to reiterate the rationale for profile URIs : if publishers
include one, they have made a clear assertion according to the
conventions of web architecture and the relevant specs that they're
using that microformat. Consumer tools which maximally respect the
intent of the publisher will check for profile URIs and proceed
accordingly. Ideally a clear distinction will be made between data
that has been extracted following the chain of authority and that
which is the result of scraping/assumptions by the scraping tool. This
certainly doesn't rule out the case of simple scraping & display, for
many purposes that's perfectly adequate. But it's ludicrous that the
webarch-friendly option isn't currently available.
More information about the microformats-discuss