[uf-new] Standards bodies (was RFC: hAudio RDFa specification)

[Brian Suda]

On 7/26/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> My argument is that the world is moving forward and creating new
> semantic formats without this community. We should not be insular and
> should take part in what is going on outside this community.

--- My view is that microformats are just one piece of the overall
spectrum. They are not designed to solve every single problem... that
is what other technologies attempt to do. RDFa is a similar system to
microformats, but more complex. We have yet to see if it has enough
"legs" to get it going. My concern is (if this were some sort of Venn
diagram) we should minimize overlap between these communities as much
as possible. The more overlap, then the more duplication of work,
which is exactly what we want to prevent. RDFa and others should, and
do, agree. So if there is a microformat to model media data, then
there is no need for an RDFa version, because you can simply create
your end RDF from the microformat! it is just another type output. To
duplicate the work and attempt to run things in parallel (1) can't be
a good use of time, (2) will eventually cause forks (3) begin to apply
RDFa ideologies to microformats and microformats ideologies to RDFa,
which in some cases are incompatible.

> There are already several initiatives to create semantic audio formats for the
> web[1][2].

--- and if those then suite your needs and the needs of publishers,
why create Yet Another Media format here? If those organizations have
a much better understand, publisher base, motivation, and encoding
format, then maybe microformats are not the best place to develop a
media format? Microformats do NOT need to solve ever single problem...
we can been seen as "a gateway drug to harder stuff".

> Let's not loose sight of the fact that we can shape the discussion in
> other communities because we have solid data to back up our semantic
> vocabularies - this is often not the case in other standards bodies.

--- I think you are confusing standards bodies and communities.
Standards bodies should be there to just ratify and make sure there is
a level of perfection, such as ISO 9001. Communities submit their
works to these bodies for approval - the lines do blur with the W3C
organizing the community of companies to design the spec, which is
in-turn is submitted to the W3C for approval as well.

Have solid data to back up semantic vocabularies is also not often the
case in different communities. With things like RDF, through the use
of namespaces, you can create anything you want. This eventually
leaves to "lets throw as much at the wall and see what sticks". Then
you get multiple formats, then you have to create another layer on top
of that to connect the means between things... this leads to the
"tower of babel problem", which we want to avoid.

> > --- this is correct, but the W3C is not the only potential standard's body.
> Are there other standards bodies that we should focus on?

--- certainly. The vCard and iCalendar RFCs are done through the IETF,
so if we want to change elements of those specs, that would be the
appropriate standards body. So far, this has not been an issue or a
real desire.... microformats seem to be ticking along just nicely
without some ISO seal of approval. I don't think we should be focused
on any standards body at the moment, we have a long way to go and a
long todo list of things to clear - we need to deal with issues that
publishers have, not worry about a standards body. Just because they
may approve something, doesn't mean it is useful, or will be used.

> We will be able to do a good job of keeping the RDFa in sync if we are
> authoring the RDFa spec as well... which is what is happening in this
> case. We should be represented in any standards body that is doing work
> similar to ours.

--- i disagree that we need to be in sync with RDFa... we don't even
have a microformats spec yet. No need to put the horse before the
cart. RDF is flexible enough that you do NOT need to track things in
parallel. You can simply use the XMDP profile to map to RDF at a later
date. Did you know that is what we are doing with hCards today? anyone
who uses the profile URI for hCards is generating RDF without
realizing it... So in my view to develop in parallel with RDFa can
only cause the 3 problems that i have mentioned above

> This Microformats specification community should be known for working
> openly with other specification communities.

--- i think there are several options here... (1) we are all
volunteers, so we can't possibly interact with every possible
specification community. (2) why are they not interacting with us? (in
many cases they are!) (3) at the end of the day some things just don't
need a rubber stamp to work. We´ve proved that in practice, now we
just need to prove that in theory! (4) not every spec out there needs
to be a microformat... i'm just waiting for someone to propose
hKitchenSink.

So, we don't need to lower ourselves to their level of red-tape,
pandering to corporate sponsors, or bottom line. Our benefactors and
our audience is internet-wide publishers - we should focus on them and
work with them rather than standards bodies. Having something "frozen"
at a standards body does NOT allow us to itterate and fix things as
easy, and therefore MUCH MUCH more time is taken to develop the
format, and then potentially it is obsolete before anyone has a chance
to use it.

> In addition, RDFa is created so that any community may create a
> specification independently of other communities. It is ideally suited
> to the Microformat community's goal of creating open standards.

--- it is the goal of microformats to create open standards, but not
independent of this community. If you want to call something a
microformat, then it must go through the process - otherwise it is
simply POSH or something else. The reason why microformats work is
BECAUSE you can't just go throw things at the wall and see what sticks
- there is a rigorous system to keep things minimal (and therefore
useful) for publishers. RDFa lets communities fragment and argue
between each other about what standard is better and therefore neither
gains any critical mass, in the meantime communities like microformats
which have a single straighforward simple message and format have
tended to win out. That's not to say there isn't a need for something
like RDFa, let them solve the complicated problems which are
out-of-scope to microformats.

> Furthermore, if there are 10 independent audio RDFa specifications out
> there, and the Microformats community has put their support behind the
> hAudio RDFa vocabulary, the choice among web publishers would be clear
> (if the uF community is respected as a standards body by that point).

--- I think web publishers would seek out the easiest, the one that
solves 80% of their issues in a very short period of time... one that
doesn't require them to learn about namespaces, ontologies, RDF,
XHTML2, or other technologies.

Is there an underlying reason for the push for "standards bodies" (if
so then maybe we should start a new threat on the discuss list)?
hCard, hCalendar and other microformats have never been "ratified" by
standards bodies and they seem to be doing pretty well. (i don't have
scientific proof, but ...) i would bet that the average "Jo Blogger"
doesn't care if hKitchenSink is an official standard. Infact, if the
Operator plugin only worked with "approved standards" when and how
would it ever use any RDFa? RDFa as a technology might be
standardized, but then each individual format would have to be as
well. This is just not practical if you want to scale.

> I am getting involved with other standards bodies because I believe that
> the publishers should be represented there as well.

--- i'm certainly not against that, i do the same.

> This is an initiative that has the publisher's needs at the forefront. It is vital
> that standards bodies know about the work that we are doing here and the
> best way for that to happen is to go to those standards bodies and
> present our research and standards there.

--- i don't disagree. But we can also use technolgies that they have
already produced and/or simply make ourselves aware to them. We don't
HAVE to always use their technologies or participate, but we should
atleast make our presence known to them, if they choose to ignore the
work of previous organizations it is their folly.

> If they do listen to us, then we are shaping the standards process
> discussion in favor of logic, reason and the publishers - which is, in
> my humble opinion, an admirable goal.

--- i think overall we might be confusing two different things.
Microformats as formats vs. RDFa formats, and RDFa as a technology.
RDFa as a technology has undergone approval from a standard's body,
whereas an RDFa media format doesn't have to, this the whole point of
your earlier quotation:

"...RDFa is created so that any community may create a specification
independently of other communities."

In this case, i think, the evagalism doesn't need to be directed at
the standards body saying "hay, look IETF, ISO, W3C, we made a new
format that models media", you should be going to the other folks who
want to create their OWN formats and talk to them directly. The fact
that there is 24 different Media formats in RDFa is NOT RDFa or W3C's
problem, it is the 24 communities that couldn't manage to talk to each
other, maybe due to patents and royalties or infighting, or
competition?

(maybe we need to add some of this to the history page) but
microformats was also created in somewhat of a backlash of the "top
down" exclusive system of some standards bodies. To join a W3C working
group your company has to pay vast sums of money (which help run the
W3C) or be an invited expert. This has lead some to the conclusion
that the W3C works on things that bigger companies pay for, not always
what may be best for the "little guys". Microformats is just one
attempt to be the flip-side, where anyone can contribute, as long as
they do so a good member of this "bottom-up" community. BarCamp is
another attempt at the flip of FOO camp.

Simply by avoiding the time, cost, and red-tap of standards bodies, we
have manage to accomplish a heck of a lot in the last 2 years
completely with volunteers.

-brian

-- 
brian suda
http://suda.co.uk