Re: [uf-discuss] added hReview-aggregate and rel-author as drafts, archived a few others, uf2 for new ufs

[Manu Sporny]

On 08/03/2012 08:32 PM, Tantek Çelik wrote:
> 2. Archived drafts/spec
> 
> In addition, I created a new section "Archived" (Ben Ward's 
> suggestion) to collect microformats that haven't really taken off, 
> that is appear to lack any major publishing/consuming support and
> have moved the following there: 
> http://microformats.org/wiki/#Archived
> 
> * hAudio

What constitutes "haven't really taken off"?
Since when do we have a timeframe for "taking off"?
Where are these definitions and time-frames documented on the site? I
couldn't find it.

Wikipedia is currently marking up over 119,555 songs and albums with
hAudio markup - why is that not enough?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?
http://manu.sporny.org/2012/mythical-differences/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Google announces Microformats/RDFa support!

[Manu Sporny]

The subject line says it all - Google just announced support for various
Microformats and RDFa!

Here's the Google FAQ page on structured data:
http://google.com/support/webmasters/bin/answer.py?hl=en&answer=99170

Here's the announcement on the RDFa mailing list:
http://lists.w3.org/Archives/Public/public-rdfa/2009May/0011.html

Congrats to everyone in the community and everyone that has helped
create a Microformat!

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Bioformats - microformats for biology

[Manu Sporny]

li...@ben-ward.co.uk wrote:
> This community very intentionally doesn't try create specifications for
> everything. Previous pure-science efforts such as species died because
> it fell way outside the area of active interest of most of this
> community's participants. 

I don't think that's the defining reason (Andy's banning, as Toby
stated, is probably the primary reason that the species uF is currently
not under development).

While I do agree that it's important that this community is careful
about what it works on, we shouldn't be exclusive and we shouldn't
assume that we know where certain community members want to focus their
attention. If a couple of people want to come into the Microformats
community to develop their vocabularies, we shouldn't say that there
isn't a place for them.

I, for one, would be interested to see how a bioformats discussion would
evolve *ba-dum-bum* =P. We're talking about the bits and pieces that
make us who we are! Allowing us to identify and process that information
could help us better understand how we're connected to each other as a
species. That seems like a fairly noble endeavor.

Ever played around with 23andme.com[1]? Being able to mark up your
personal genome on 23andme and have the browser cross-link against
SNPedia[2] automatically would be really awesome.

In short, we could help them work through some of the more subtle
language and vocabulary issues while helping an initiative that could
very well benefit the human condition. The discussion may come to
nothing, but let's give it a chance before shutting it down prematurely.

-- manu

[1] https://www.23andme.com/about/
[1] http://www.snpedia.com/index.php/SNPedia

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Website Launch
http://blog.digitalbazaar.com/2009/01/16/bitmunk-3-1-website-launch
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Bioformats - microformats for biology

[Manu Sporny]

André Luís wrote:
> http://bioformats.org/
> 
> Why is this being developed outside of this community?

Possibly because they don't quite understand how the Microformats
Process works. I know our first impression was that we didn't need to
perform any sort of centralized development through the Microformats
community. We believed that Microformats could be developed by anybody
on the web and there was no "stamp of approval" necessary to call what
you were doing a "Microformat". At first blush, it wasn't clear that
there was a process behind what this community does...

> Has anyone heard of this before and/or have contacted the 
> founders of this project?

I've notified them of this thread.

> Bottom line is.. should we care about this? 

Yes, we should. They have demonstrated buy-in to the semantic web at
some level, interest in Microformats, the ability to do some work and
publish in a way that is open, and they're backed by an institute -
which means that probably have more time and interest than most to work
on this stuff.

> Try to invite them to join the community and discuss the pros 
> and cons of their proposals? Or just leave them be?

It would be a mistake to not invite them to join and let them decide if
this community is the best avenue forward. We shouldn't assume what the
interests of this community are - this mailing list has over 1,000
readers and all you really need is 2-3 highly motivated individuals to
push some of these initiatives forward.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Website Launch
http://blog.digitalbazaar.com/2009/01/16/bitmunk-3-1-website-launch
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hProduct draft now available

[Manu Sporny]

Myers, Jay wrote:
> After several months of diligent work, I'm happy to announce the draft
> spec of the hProduct microformat, linked from the front page of the
> wiki. I look forward to your constructive feedback in order to better
> the format for eventual adoption. 

Hi Jay,

Glad to see that you have decided to take the lead on moving the
hProduct uf forward :)

I haven't been following the hProduct discussion that closely and this
was really the first time I took a look at the draft. I'd like to draw
your attention to a particular Microformat Process issue that you may or
may not know about...

> As per the process, we have included
> appropriate wiki pages for issues, faqs and examples. 

The hProduct examples page[1], including all example pages that it links
to[2][3], include around 11 example sites, with no mention to the number
of sites that were analyzed. One of the first steps that should be
completed before a Draft is proposed is extensive analysis of existing
websites providing products.

To put hProduct's 11 examples into perspective, hAudio had close to 84
examples for the online music store section alone. If you have the
analysis data that led to the current version of hProduct, please put it
on the wiki. We can't know if the vocabulary terms are a good choice
unless we have the data to back up the draft.

For example, here's the analysis of terms utilized in audio sites:

http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services

Is there an equivalent for hProduct? If not, is there a full set of
analysis data that backs up the vocabulary generated for hProduct?

-- manu

[1]http://microformats.org/wiki/hproduct-examples
[2]http://microformats.org/wiki/product-examples
[3]http://microformats.org/wiki/hlisting-extended-examples
[4]http://microformats.org/wiki/audio-info-examples

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.

blog: POSIX Threads Don't Scale Past 100K Concurrent Web Requests
http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1

blog: Fibers are the Future: Scaling Past 100K Concurrent Requests
http://blog.digitalbazaar.com/2008/10/21/scaling-webservices-part-2
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Announcing Oomph: A Microformats Toolkit

[Manu Sporny]

> On Wed, Oct 22, 2008 at 10:46 AM, Karsten Januszewski
> <[EMAIL PROTECTED]> wrote:
>> Greetings - I'm excited to announce the release of Oomph: A Microformat 
>> Toolkit, 
> which just went live at http://visitmix.com/lab/oomph.

Great stuff, Karsten! Looking forward to seeing where this goes... what
are the next steps, if you're allowed to elaborate? Where are you
putting your efforts for the next 3-6 months regarding Oomph? Supporting
more Microformats? Doing more stuff like Ubiquity[1]?

What are the future goals for Oomph?

-- manu

[1] http://labs.mozilla.com/2008/08/introducing-ubiquity/

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.

blog: POSIX Threads Kill: Scaling Past 100K Concurrent Web Requests
http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1

blog: Fibers are the Future: Scaling Past 100K Concurrent Web Requests
http://blog.digitalbazaar.com/2008/10/21/scaling-webservices-part-2
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] How about adding aRecipe, an RDFa serialization of hRecipe?

[Manu Sporny]

Thomas Loertsch wrote:
>> I'm not sure that an RDFa serialization is something that needs
>> endorsement or hosting by microformats.org. Once hRecipe is
>> formalised, RDF/RDFa-based work that uses the hRecipe vocabulary needs
>> no input from microformats.org. The syntax for the RDFa is derived
>> simply from the RDF/OWL model - there's nothing there that needs
>> deciding on. 
> 
> There are still things that can go wrong - you confirm that below when you
> propose to draft a mapping and post that as N3-Draft on the web to solicit
> comments. My question is if microformats wouldn't be a good place to do just
> that. It's the question if we need another site, another organisation to
> develop vocabularies and/or serializations in a community-process or if, at
> least if a proposal with a microformats-syntax is already active, can add a
> RDFa-serialization project to it?

Clearly stating the RDFa equivalent of Microformat markup would be
beneficial to website authors. This would also halt duplication of work
in both the Microformats and RDFa communities and thus would be
something that is beneficial to the semantics community at large. We
don't want other communities duplicating work done in this community.

I'd like to point out that hAudio has gone through this already and it
would be really nice if we could clearly state what the RDFa equivalent
of hAudio is without having to host the RDFa vocabulary elsewhere.

What would be even better is a unified syntax for expressing both
Microformats and RDFa, as described here:

http://rdfa.info/wiki/RDFa_Vocabularies#Creating_a_document_that_uses_microformat_terms_via_RDFa

If the preceding proposal were pushed forward and adopted, it would mean
that any Microformats vocabulary would automatically be RDFa-izable and
that we would have a unified syntax for expressing both RDFa and
Microformats.

Food for thought.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Today, Tomorrow, and Someday Problems

[Manu Sporny]

Tantek Celik wrote:
> eventually decided that it was time that someone started to experiment
> with the broad semantic HTML *today* work being done by modern web
> designers, solving today's real world web problems, with shared
> vocabularies based on existing standards. I met up with Kevin Marks
> who had similar ideas and microformats was started.

That being said, I owe a great debt to this community and the people
that started it and continue to contribute, including you and the other
uF founders, because it is here that I first saw that the semantic web
was achievable in the near term.

With over a 1,900 directly involved in this community, it is clear that
the idea behind Microformats is something that resonates with us!

The issue I had was with the execution of Microformats - most notably,
the process and the parsing rules. It was only after hAudio ground to a
halt (the second time) due to the many arguments revolving around the
decision to not use "TITLE", pseudo-namespacing, scoping, accessibility,
etc., that I followed up with the W3C as I became increasingly
frustrated with the process.

Our start-up had a problem to solve (mark-up of audio on web pages) and
we wanted to do it right, through a standards body of some kind, instead
of forcing our view on the world. We were determined to start an
initiative to make the W3C take semantics in HTML more seriously. To our
surprise, we found the RDFa Task Force who were doing just that.

> That was years ago (2003-2004). In the meantime, microformats 
> adoption has taken off much faster than any of us could have 
> hoped for, while XHTML2 is largely ignored. XHTML2 wasn't a 
> "tomorrow" technology 5 years ago [1], and it still isn't 
> today.
> You could say there may be some
> bitterness/resentment/jealousy/denial about that.

I joined the W3C as someone who was bitter about many of the standards
that had passed the process. The nastiest scar that we held was a
system-wide implementation of SOAP as our messaging protocol only to
find out that the entire protocol was horrifically over-engineered. "It
came from the W3C, it must be good", we thought. Similarly, we had
issues with HTML 4.01 and a variety of other W3C technologies throughout
the late 1990s and early 2000s.

I don't take a strong position on XHTML2 or HTML5 because I have learned
enough to know that there are too many people that want too many things
out of both technologies to say that either standard is "good" or "bad",
or solving today/tomorrow/someday problems. Everybody has different
priorities and depending on one technology to solve all of our problems
is never the answer. It's going to be a mix (HTML5, XHTML2, Javascript,
Microformats, RDFa, etc.) like it has always been on the web.

> Anyway, I'm largely ignoring it, as I'm trying to do my best 
> to ignore the "microformats vs RDFa" baiting / 
> artificial-dichotomy that so many have pursued. We have 
> too much productive work to do to be distracted by such drama.

Agreed. There is too much work to be done and that getting involved in
the perceived drama is distracting.

When I hear someone talk about the "drama" between XHTML2 and HTML5, or
Microformats and RDFa, it is usually in the form of false perceptions
that one community has about the other.

This is interesting because it breaks down into two categories:

- People that think there is drama due to false perceptions on the
positions that the other community holds. "The RDFa community is waging
war on the Microformats community - I read about it in a blog post", or
"The Microformats community thinks RDFa is just a repeat of RDF/XML."
- People that have been burned by one community or the other in the
past, usually during a design argument, which clouds their desire to
work with the community ever again.

So rather than actual drama, we have perceived drama because the
communities aren't talking. We are letting false perceptions or negative
experiences that we have had in the past cloud our ability to work with
each other.

This isn't directed at you, Tantek, as I know you strive to make your
reasoning and thinking as fair and logical as possible. It's directed
more at the general community (both RDFa and Microformats).

There are a number of very good thinkers in each community and it is a
shame that they continue to be separated because of false perceptions
and clouded judgement.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Today, Tomorrow, and Someday Problems

[Manu Sporny]

Martin McEvoy wrote:
>> http://halindrome.blogspot.com/2008/09/why-we-do-what-we-do.html
>>   
> Thanks Manu for an interesting post, I have made some comments ;-)
> I am a bit worried  about Shane's other post
>
>> Shane wrote:
>> Unlike microformats, the idiom for annotating your content does not
>> conflict with the normal semantics of (X)HTML (e.g., the class
>> attribute, the title attribute, and abbr).
> 
> Sound's like a declaration of war from a community who wants to bring
> Microformats to the fold.

I've been working with Shane to get this "Microformats expression using
RDFa" mechanism operational. I can assure you that his statements are
absolutely not any sort of "declaration of war". Please refrain from
using loaded language - it mis-characterizes and over-dramatizes his post.

We're not talking about a terrible conflict involving loss of life.
We're talking about a difference in opinion regarding web semantics
expression - it's really geeky stuff. :)

Shane has spent the most amount of time out of all of us in the RDFa and
Microformats communities writing up our thoughts on Microformats
expression using RDFa:

http://rdfa.info/wiki/RDFa_Vocabularies

He wouldn't be doing that if he wanted to harm this community in any
way. We're trying to bring the two communities together - not push them
apart.

>> Why would you want to use RDFa? For the same reason you want to use
>> microformats. Because you care about machines understanding what is on
>> your page, not just humans.
> 
> Is it not the other way around in the microformats community?

As Sarven stated, the RDFa community and the Microformats community
goals are the same - to enable widespread use of semantics in web
documents. While the paths that both communities have taken are
different, the destination is the same.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Today, Tomorrow, and Someday Problems

[Manu Sporny]

Interesting blog post by Shane McCarron of XHTML2 fame. He has been
involved in the standards community since 1985. His name is on just
about every major HTML standard to come out of the W3C - if you use HTML
4.01, XHTML1.0, XHTML 1.1, or will use XHTML2 (to name a few), you're
using specs that he had a direct hand in creating or maintaining.

It's interesting to see his take on how the W3C and the Microformats
community fits into the ecosystem of solving the problems of today,
tomorrow and "someday". The post discusses Microformats and RDFa:

http://halindrome.blogspot.com/2008/09/why-we-do-what-we-do.html

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] HTML5+RDFa discussion on WHATWG involves Microformats

[Manu Sporny]

Samuel Santos has started blogging about the HTML5 + RDFa/Microformats
discussion that we've been having in WHATWG:

http://www.samaxes.com/2008/08/29/the-semantic-web-and-rdfa/

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force

[Manu Sporny]

Scott Reynen wrote:
> That, or we'd compromise RDFa. 

I can almost guarantee that neither side is going to compromise their
set of beliefs. The Microformats community is too hard headed to do so,
and the RDFa community has a very long, arduous W3C process to consider
when changing anything major in the RDFa specification.

> As the two efforts have somewhat
> divergent priorities, I don't see how we could combine them without
> compromising on one side or both. 

Let's give it a shot, give it a number of months, and see if either side
feels like they're compromising on anything. I believe that approach is
better than saying that it's impossible, throwing up our hands and
giving up before we've even started.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Potential for Microformats.org to work with W3C andRDFa Task Force

[Manu Sporny]

Tantek Celik wrote:
> Completely agreed w all of Ben Ward's points.

Even the ones that seem to state that RDFa does not operate in the realm
of HTML? The reason I raise this point is that RDFa will be a W3C
standard, applicable to XHTML1.1 and XHTML2 by the end of October 2008
(roughly). We're in the process of working out a HTML4+RDFa DTD and
validator for HTML 4.01 as well.

This will cover all current HTML family languages, so stating that RDFa
is "outside" of HTML will only be accurate until the end of October
2008. After that, RDFa will be a part of all deployed HTML family languages.

> In addition - I would be very concerned that the microformats 
> principles would be compromised by any such efforts as Manu suggests,
> and efficiency of parsing/parsers and other points listed are not
> worth compromising the principles.

Nobody is suggesting that anybody compromise their principles. What I'm
suggesting is that we may have figured out a way to bring a unified
semantic data processing mechanism to RDFa and the Microformats
community, across all current HTML family languages, without changing
either community's approach to semantic data markup.

If we're correct, it means a great deal of progress will have been made
in both communities - all I'm asking for is that we cooperate with the
W3C, are given the chance to do the work, and to see what falls out.

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force

[Manu Sporny]

Ben Ward wrote:
>> It will take a couple of weeks to give examples of how this will all
>> work, but I wanted to get feedback from this community before
>> proceeding. We have a fantastic opportunity in front of us now - who in
>> this community thinks that we should work with the W3C on this endeavor?
> 
> I'm not sure I completely see the benefit in this, and seeing your
> examples would be very helpful in getting a better idea of what you're
> proposing. 

I'll get a set of examples written up soon, then.

> From your bullet points, it seems to suggest taking
> microformat vocabularies and expressing them in RDFa, rather than HTML?
> It seems redundant for publishers.

No, the markup would still happen in HTML, using Microformat properties,
but instead of using @class, we MAY (not MUST) use @typeof, @property,
and @content (in the case of machine-readable data) to express
Microformats.

The key being that these attributes are specifically designed to contain
semantic data. Here's a brief example showing how we could get rid of
the ABBR design problem by re-using RDFa's @content attribute. Note that
this would work in HTML 4.01, XHTML1.1 and XHTML2:


   Start Wearing Purple by
   Gogol Bordello
   May 14th, 2002


> However, I do have a somewhat related issue that you might consider part
> of this effort. Some discussions I've had lately revealed usefulness in
> being able to _map_ microformats into RDF, for the purpose of combining
> microformats with other RDF vocabularies in a back-end somewhere (so,
> conversion for processing, rather than publishing. Publishing remains in
> HTML where it is most effective).

Publishing would stay in HTML, where it is most effective. Nobody is
suggesting that it move elsewhere - RDFa follows the same principles as
Microformats in this case.

As for the mapping between uF/RDF Vocabularies, I started a page to do
just that back in October 2007:

http://wiki.digitalbazaar.com/en/Mapping-ufs-to-rdfa

Want me to move it to Microformats.org?

> I'm told that RDF ‘versions’ of vcard and icalendar are out of date
> compared to the microformats. 

I don't think they are, but could be mistaken...

The last update to VCARD was on 22 February 2001:
http://www.w3.org/TR/vcard-rdf
and the vocabulary:
http://www.w3.org/2001/vcard-rdf/3.0#

The last update to iCalendar was on 29 September 2005
http://www.w3.org/TR/rdfcal/
and the vocabulary:
http://www.w3.org/2002/12/cal#

> As such, it strikes me that rather than
> maintaining duplicate specifications, it would instead make sense to
> develop a set of standard transformations so that any microformat can be
> transformed from HTML to RDF, without requiring duplicate effort to
> maintain another spec. This I'm sure would relate closely to GRDDL,
> since that already deals with transformation.

Yes, agreed, that would be useful.

> Note, I'm talking about mapping rules, not separate specs. For example,
> we have the ‘jCard’ page on the wiki, which I still feel should be more
> generic ‘JSON Mapping Rules’ page that can cover parsing from any
> format, not just hcard. 

We're also working on that in our company, but internally for now. There
is the issue of a generic object representation format for semantic data
objects. We have a generalized RDF-based representation for RDFa and
Microformats now... but didn't think this community would be interested
in such a solution. Should a wiki-page be started on various "JSON
Mapping Rules" between uF/RDFa to JSON?

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] HTML5, Microformats and RDFa

[Manu Sporny]

André Luís wrote:
> Manu,
> the css based approach is somethin that has come up in discussions
> about semantics with fellow workers. I believe it does not trash all
> of the hard work the communities have don so far.

I never said the discussions "trashed" all of our hard work. I said that
some of the discussions "ignore" (some) of the hard work performed by
this community as well as the RDFa community.

> All it does, from
> what i gathered, is move the semantics from html and places it in a
> separate file/place.

Right - which both this community and the RDFa community are opposed to:

1. We do not want semantics to be placed in separate files.
2. We do not want vocabularies to be re-defined from site to site.
3. We want semantic markup to be easy to author for regular people - CSS
   is /not/ easy to author.

That's what I was attempting to point out with my statement. Apologies
if I was not clear :)

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force

[Manu Sporny]

Hi uFers,

RDFa is going to become an official W3C standard in the next 2-3 months.

Martin McEvoy had posted something about two weeks ago on the RDFa
mailing list stating that he'd like to use RDFa to express Microformats:

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Aug/0081.html

At first, I dismissed it as something this community would not be
interested in, and even if they were, something that the RDFa community
wouldn't be interested in doing. Shame on me for assuming without
checking with both communities first! Over the past week, I've been
thinking about some of the stuff Mark Birbeck (who started the RDFa
initiative) said several months ago and what Martin re-iterated in his
e-mail two weeks ago:

There should be a way to provide Microformats-like markup using RDFa.
Afterall, it would solve the unified parser/markup issue that some
(both inside and outside this community) have with Microformats.

So, I drew together a very quick proposal before the RDFa Task Force
meeting this morning:

It is possible to use RDFa attributes to replace/enhance usage of the
@class attribute and the ABBR design pattern in Microformats. We should
be able to do so without introducing the concept of namespaces to the
author that is marking up content - keeping the simplicity of
Microformats authoring intact. Doing so would provide a unified model of
semantics expression between RDFa and Microformats. It would also
provide one unified parser that could parse both namespaced RDFa and
non-namespaced Microformats.

Here's a link to the discussion:
http://www.w3.org/2008/08/28-rdfa-minutes.html#item03

The group was very enthusiastic - they would like to work with the
Microformats community to address some of these long standing issues in
our community. If we are successful in this endeavor, it would mean:

- 9 additional parsers that could parse Microformats.
- A unified parsing model in addition to the ad-hoc one provided by
  Microformats.
- A full test suite for the unified parsing model.
- A unified method of Microformats and RDFa expression in HTML4,
  XHTML1.1, and XHTML2.
- A painless upgrade path from Microformats to RDFa if the author so
  desired.
- A solution to the ABBR accessibility problem.
- A solution to the Microformats containment problem (class="item").
- A solution to the mfo problem.
- A unified method of semantics expression for the web.

It will take a couple of weeks to give examples of how this will all
work, but I wanted to get feedback from this community before
proceeding. We have a fantastic opportunity in front of us now - who in
this community thinks that we should work with the W3C on this endeavor?

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.0 Website Launches
http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] HTML5, Microformats and RDFa

[Manu Sporny]

Scott Reynen wrote:
> I think comparing RDFa to microformats actually hurts your argument by
> suggesting they solve the same problem and reinforcing the notion that
> the wider problem RDFa seeks to solve is unimportant.  Rather, I would
> interpret the mentions of microformats as an indication that people are
> missing the wider problem RDFa would solve, and focus on making that
> clearer, by talking about what RDFa does that microformats don't even
> attempt to do.

Scott, Ben - thanks for the feedback, both of you make some very good
points and I've adjusted my argumentation a bit to follow advice
expressed by both of you. Things are being clarified in some ways on the
HTML5 list and muddied in others.

The one thing that is clear is that most of those on the list are not as
up-to-speed with web semantics as either this community or the RDFa
community would expect. Certainly, I was a bit blind-sided by some of
the false assertions those on the list were making about semantics in
general.

The very long thread continues,

RDFa Problem Statement and Features
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015957.html

Intro to RDFa
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015974.html

RDFa markup consistency
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015992.html

CSS-based approach to semantic data on the Web (Microformats and RDFa)
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015996.html

Of particular note is the last thread - the CSS-based approach to
semantic data markup. It's a proposal that, while interesting, ignores
the hard work that this community and the RDFa community has done over
the past several years. I could be mis-reading the various threads, so
some feedback from this list would be appreciated.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.0 Website Launches
http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] HTML5, Microformats and RDFa

[Manu Sporny]

There have been several threads discussing Microformats, RDFa and HTML5
that are occurring on the WHATWG mailing list. The discussion relates to
whether or not HTML5 should depend on the Microformats community to
solve HTML5's semantic markup issues, or if both Microformats and RDFa
should be considered for semantic web markup issues.

The start of the discussion is here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015860.html

and continues here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015875.html

I have authored a blog reply, stating that HTML5 should not depend on
the Microformats community to develop all semantic web vocabularies, the
reasoning can be viewed here:

http://blog.digitalbazaar.com/2008/08/23/html5-rdfa-and-microformats/

and my first response to the WHATWG mailing list

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015949.html

Things start getting dicey here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015892.html

and here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015950.html

and my second response to the WHATWG mailing list, outlining some of the
shortcomings of Microformats and stating what differentiates RDFa in
it's approach:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015957.html

Posting to this list because there are many on here that would be
interested in the WHATWG's current position on web semantics: "not
important enough to consider as part of the HTML language". Note that
the XHTML1.1 and XHTML2 workgroups have already accepted the position
that: "web semantics are important and a standard method of semantics
expression is necessary for the future development of the web".

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Mozilla Labs Aurora mock-up depends on RDFa/uF-like technology

[Manu Sporny]

Mozilla Labs announced a pretty cool new browser concept dubbed Aurora.

It's pretty flashy and integrates some experimental UI concepts that are
questionable. However, one of the fundamental, underlying principles of
the browser is the concept of data portability. The idea that you own
your data and can pipe, mix and match data from different websites was
key to the browsing/collaboration experience.

I caught myself thinking "You'd use RDFa/uF to do that... and that...
and that" throughout each video. Here are the direct links to Vimeo
WebHD content:

Aurora - Part 1 - Collaboration, History, Data Objects, Basic Navigation
http://www.vimeo.com/1450211

Aurora - Part 2 - Geo-location-based browsing
http://www.vimeo.com/1476338

Aurora - Part 3 - Integrating Web w/ Physical Environment (also, sexism)
http://www.vimeo.com/1481810 (non-WebHD)

Aurora - Part 4 - Personal Data Portability
(bonuses: copious diversity and "the liberal agenda")
http://www.vimeo.com/1488633

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.0 Website Launches
http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Audio/Video RDF Vocabulary Screencasts

[Manu Sporny]

Hi uFers,

Based on work that was done in this community over a year ago, we've
attempted to do a port of hAudio over to the RDFa world. The result is a
set of 4 vocabularies for media, audio, video and commerce. We used a
number of Microformats principles when porting the vocabularies and
re-using pre-existing vocabulary terms. We re-use Dublin Core heavily.
The vocabularies can be found here:

http://purl.org/media/
http://purl.org/media/audio
http://purl.org/media/video
http://purl.org/commerce

A small plugin, named Fuzzbot, has been put together to explore semantic
web UI approaches and two demos are now up regarding the audio and video
vocabularies:

Intro to Fuzzbot and Audio Vocabulary
http://www.youtube.com/watch?v=oPWNgZ4peuI

Intro to Video Vocabulary
http://www.youtube.com/watch?v=PVGD9HQloDI

The intros are very rough, done in 1-2 takes, but hopefully they get the
concept across. The next steps are going to be an attempt to use Firefox
3's Microformats functionality to pull uF metadata into Fuzzbot's RDFa
triple store.

Downloads and source for librdfa and Fuzzbot can be found here:

http://rdfa.digitalbazaar.com/fuzzbot

The Linux version is the only one that is up-to-date. I'll compile the
Mac OS X and Windows versions when I get the time to do so.

Feel free to comment/discuss the videos on here. We're looking for
feedback on what would make the demos more enticing. Right now, it's
just "you can use metadata to construct more accurate searches".

-- manu

PS: I also mis-spoke at one point in the first video and said that
"before Fuzzbot it wasn't possible to do this sort of thing", which is
not correct 'cause Operator has been around for a much longer time.
Apologies to Mike Kaply, since he started blazing this trail some time
ago. :)
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Microformats and RDFa not as far apart as previously thought

[Manu Sporny]

There have been some interesting blog posts by people at the BBC,
Mozilla and W3C about Microformats and RDFa in the past two days. The
first covers BBC's decision to drop support for the abbr-based design
pattern written by Michael Smethurst (who worked with this community on
hAudio among other things):

Removing abbr-based Microformats from BBC
http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml

The second is a response from John Resig, of jQuery/Mozilla fame, here:

BBC Removing Microformat Support
http://ejohn.org/blog/bbc-removing-microformat-support/

The third is written by Mark Birbeck, who is the guy that proposed RDFa
several years ago and is the primary one behind the processing rules and
architecture for RDFa:

Microformats and RDFa are not as far apart as people think
http://internet-apps.blogspot.com/2008/06/microformats-and-rdfa-are-not-as-far.html

We've had discussions that parallel the ones above last summer:

http://microformats.org/discuss/mail/microformats-new/2007-July/000592.html
http://microformats.org/discuss/mail/microformats-discuss/2007-October/010850.html
http://microformats.org/discuss/mail/microformats-discuss/2007-October/010859.html
http://microformats.org/discuss/mail/microformats-discuss/2007-October/010879.html

I tend to agree with Edd Dumbill's post:

http://times.usefulinc.com/2008/06/24-uf-rdfa

Some are moving too quickly to dismiss both Microformats AND RDFa - the
two communities are cross-pollinating and there has been significant
lessons learned from both approaches. If you're going to blog about this
or discuss it - please don't fuel the Microformats vs. RDFa fire by
picking sides... it's detrimental to both communities.

Like Edd stated in his post, we have a bug that we need to fix (abbr
design pattern causing screen reader usability issues) and that has been
hanging over our heads for some time now. BBC's decision is a lesson
learned but is in no way some sort of sign that Microformats is on it's
way out.

Thoughts from the community? Anybody else blogging about this?

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Blacksburg BarCamp 1.0
http://blog.digitalbazaar.com/2008/05/15/blacksburg-barcamp-10/

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Practical Web Semantics - Talk at Rackspace

[Manu Sporny]

Hi all,

I ended up giving a Tech Talk at Rackspace at the end of April on
Practical Web Semantics. This included discussions concerning basic
semantics, Microformats, RDFa, and demos including Operator and Fuzzbot.

The overview page is here:

http://wiki.digitalbazaar.com/en/practical-web-semantics

Here are quick links to each section:

Practical Web Semantics Part 1 of 4: Introduction to Digital Bazaar
http://wiki.digitalbazaar.com/talks/practical-web-semantics/part1.html

Practical Web Semantics Part 2 of 4: Basic Semantics and Microformats
http://wiki.digitalbazaar.com/talks/practical-web-semantics/part2.html

Practical Web Semantics Part 3 of 4: RDFa Concepts
http://wiki.digitalbazaar.com/talks/practical-web-semantics/part3.html

Practical Web Semantics Part 4 of 4: Demos and Questions
http://wiki.digitalbazaar.com/talks/practical-web-semantics/part4.html

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Dynamic Spectrum Auctions and Digital Marketplaces
http://blog.digitalbazaar.com/2008/04/24/dynamic-spectrum-auctions/

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] My inactivity

[Manu Sporny]

Ben Ward wrote:
> Just a little note to explain that my µf tasks: hListing, ABBR-pattern,
> ‘This Week’ posts are on hold at the moment as I made a rather
> unexpected trip into hospital this week. No need to worry; after five
> days I've been released again (my appendix had gone rotten and has been
> removed).
> However, I'll be resting for most of this week

Sorry to hear about your trip to the hospital. Hope all is going better
and that you have a quick and speedy recovery.

I'd be happy to put together a "This Week" blog post, who should I send
it to? You, Tantek, or somebody else?

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Dynamic Spectrum Auctions and Digital Marketplaces
http://blog.digitalbazaar.com/2008/04/24/dynamic-spectrum-auctions/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] rel="nsfw"

[Manu Sporny]

Gordon Oheim wrote:
> I was just reading a blog about bad use of Photoshop that linked to
> "not-safe-for-work" sites every now and then. Made me wonder if we could
> use a microformat that indicates "non-suitable for work" links and the
> likes? I could imagine a FF plugin that recognizes page elements tagged
> as nsfw and changes their display to none or something like that when
> you are at work. Could also use nsfc (for children). Google could crawl
> this and protect my unborn kids. What do you think? Useful?

I certainly think that this is a very useful concept and merits further
discussion on microformats-dev.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Dynamic Spectrum Auctions and Digital Marketplaces
http://blog.digitalbazaar.com/2008/04/24/dynamic-spectrum-auctions/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Digg Rolls Out DataPortability Enhancements

[Manu Sporny]

Surprised the semantic story du jour hasn't been posted to this list
yet. Congrats to the XFN, and hCard folks :)

http://blog.digg.com/?p=120

PS: Steve Williams is a good guy - he really does care about this stuff.



Digg Rolls Out DataPortability Enhancements
by Steve Williams at 12pm, May 1st, 2008 in Digg Website

Hey all,

The Data Sharing Summit in San Francisco was a gas. It was a real
pleasure to work with like-minded people from organizations, large and
small, all supporting DataPortability.

At the Summit I had the chance to show off Digg’s latest DataPortability
enhancements. Although the enhancements are not visible on Digg.com, if
you use Digg together with other social networks, these enhancements can
make the Web more fun and useful.

Among the recent enhancements:

- We’ve added XFN to your user profile. XFN is an open standard that
makes it easier for other social Web sites to recognize your Digg friends.

- We’ve improved support for hCard, another open data format for
communicating Digg user names, nicknames, and photos, so that your
favorite friend-following tools can more easily display your friends’
activity.

- We’ve added RDFa, making Digg part of the “semantic web” where Web
pages become more sophisticated, beyond simply words and pictures.

These efforts support our philosophy that you own your data.

Thanks,

sbw

--

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Fuzzbot - An embedded semantic data viewer

[Manu Sporny]

Fuzzbot is designed to detect RDFa and other semantic data formats and
display them to the person browsing. RDFa is a way to embed
machine-readable data into web pages, which helps computers help you
interact with web pages in a smarter way. For example, Fuzzbot can show
you information about people that it has found on a web page - helping
you view only the data in which you're interested.

The goal of Fuzzbot is to integrate Microformats and RDFa into a common
format (JSON/RDF) which authors can then write Actions and UIs against.
What this means is that Fuzzbot will deal with higher-level semantic
concepts (People, Places, Events, Audio, Video, etc.), rather than
formats (hCard, FOAF,  etc.). Fuzzbot is primarily a test bed for UI
concepts and is not a replacement for Operator - ideally, some of what
we learn from Fuzzbot could be integrated into Operator.

http://rdfa.digitalbazaar.com/fuzzbot/

Screenshots are available here, for those that don't want to install the
plugin:

http://rdfa.digitalbazaar.com/fuzzbot#screenshots

Some of you might note that the primary UI concept behind Fuzzbot is
based on Dmitri Glazkov's Margin Marks concept[1] that he posted to this
mailing list about 3-4 months ago. It is a visual approach to displaying
semantic data.

The current release (v0.7.5) is a very preliminary version of the
software. There will be UI bugs and perhaps some operational bugs (For
example, parsing Digg.com is very slow). Firefox XPIs are available for
both Linux and Windows, here:

http://rdfa.digitalbazaar.com/fuzzbot/download/

All librdfa source code is released under LGPL v3, and the Fuzzbot
plugin is released under the Mozilla Public License. Source code is
available via GIT:

git clone http://rdfa.digitalbazaar.com/fuzzbot.git
git clone http://rdfa.digitalbazaar.com/librdfa.git

If you have any thoughts or questions on the direction of this project,
or where you'd like to see it headed, please discuss on the list and
we'll try to work it into the project plan.

-- manu

PS: We're also looking into creating a native C library to do
Microformats parsing, but wanted to make sure there wasn't anybody that
had already done this. Is there anybody on here that has created a
native C library for parsing Microformats?

[1] http://glazkov.com/blog/margin-marks/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Request for Microformats.org MediaWiki SQL data

[Manu Sporny]

This is a request for the Microformats.org MediaWiki MySQL database
data. If one of the admins could do a mysqldump of the database (or
selected tables) and place it onto a public HTTP/FTP site, that would be
ideal.

WARNING: Do not dump the password or e-mail field for the user table.

I'd like to run an analysis on the number of contributions made by
everyone involved in this community and attempt to write an algorithm to
detect edit wars.

This request is two-fold:

1. I'm curious to see who the most prolific wiki contributors are and if
   they have any correlation with the most prolific mailing list
   contributors.
2. It would be good to have an automatic process that could detect and
   log wiki edit wars, thus reducing the load on the admins and the rest
   of the community.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: RDFa Basics (video)
http://blog.digitalbazaar.com/2008/01/07/rdfa-basics
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Unjust banning of Andy Mabbett

[Manu Sporny]

Drew McLellan wrote:
> The simple fact is that the microformats community is *not* a lot of
> work, save for the disruption Andy has caused. That we even seen to
> spend effort having this conversation rather than working on
> microformats is further evidence of that disruption.

Drew,

We are spending effort having this conversation because governance is
vital to the health of this community. Talking about the method employed
to execute this ban is certainly not a waste of time. Talking about
contributions of community members is certainly not a waste of time, either.

If nobody had a problem with the admins' decision, you would have seen
my initial e-mail and silence thereafter. However, there have been a
number of people that have voiced a similar concern. To date, 10 people
have voiced concern about the length of Andy's ban and the methods used
to ban him. That is a clear indicator that there is a disconnect between
the admins and the community.

This isn't just about Andy - it is also about the methods employed by
the admins to come to this decision:

- Lack of a documented process for bans.
- Lack of proper documentation leading up to Andy's ban.
- A vote count for the admins (for and against).

At the very least, if we don't have a process in place, we should follow
Wikipedia's ban procedure[2].

To place the blame of this "disruption" squarely on Andy's shoulders is
to ignore the fact that the admins are the ones that brought about the
18 month ban. It also ignores the fact that proper due diligence was not
performed before the ban.

This would be happening if it were Andy, or anybody else on this list.
We are spending the effort to have this conversation because we don't
like what we're seeing.

Just to be clear, here's what the expectations are:

- The admins reply to each point in the initial e-mail that started this
  thread[1]
- The admins create a procedure for banning individuals from the
  Microformats community.
- The admins fully document Andy's ban, similar in scope to Wikipedia[2]

If you want to focus on making this community run smoother, focus on
those things and the next time something like this happens, we won't
have to re-hash this discussion.

-- manu

[1]http://microformats.org/discuss/mail/microformats-discuss/2008-March/011713.html
[2]http://en.wikipedia.org/wiki/Wikipedia:Requests_for_arbitration/Pigsonthewing

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: RDFa Basics (video)
http://blog.digitalbazaar.com/2008/01/07/rdfa-basics
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Unjust banning of Andy Mabbett

[Manu Sporny]

Derrick,

I'd like to address each of your statements as they seem to be assuming
things that were not said in the post to the mailing list.

Derrick Lyndon Pallas wrote:
> 1.) Quantity != Quality. (Maybe Web 2.0 decided otherwise, but I'm old
> school.)

The argument that quantity == quality was never made. A set of data
points were given noting Andy at the top of the lists. It would be quite
daft to make an argument stating that quantity == quality.

The point I was making was that one can't look at those numbers and
write off Andy Mabbett's contributions to this community any more than
they can write off Ryan King, Tantek, Scott Reynen, Brian Suda and David
Janes's contributions. They have all had a large impact on this community.

> 2.) No one person is worth more than the cohesiveness of a community in
> the case of community development.

Agreed. Nobody is arguing against that point.

I fail to see how Andy Mabbett has single-handedly caused the
cohesiveness of this community to be greatly diminished. If anything, I
would fault the way these issues have been handled for causing harm to
the cohesiveness of this community.

Namely, lack of administrative transparency and undocumented banning of
this community's members.

Andy's not completely innocent, nor are the admins without fault.

> 3.) Andy != Gandhi. Overthrowing the rule of a foreign power is
> unrelated to anything that happens in the microformats community or as
> part of the process. Furthermore, it is a mistake to conflate pushing
> the limits of the microformats process and its community with pushing
> the limits of the purpose of the community or of civility.

Ha! You are correct. Andy certainly isn't Gandhi. Far from it. Andy is
no saint - he has his flaws, as do we all.

Note that I am going to no trouble to argue against the prior 1-2 month
bans that have been imposed on Andy. Those bans were short enough to not
strike a nerve, even if they were not well documented.

On the other hand, an 18 month ban raises several red flags.

Andy's incivility has been primarily directed at the admins and has been
focused on how they process administrative issues. He asks very
important questions about how this community governs itself. He is often
ignored by the admins, which results in heated arguments further
resulting in a 1-2 month ban.

We would like to believe that we are all equals here, that ideas are
more important than the person behind the idea, and that the rules apply
equally to all of us.

Andy points out every occurrence of when the principles above are
broken, especially when one of the admins are the ones that break the
rules, and has thus gained the ire of the admins and some of the community.

> 4.) In August, Andy will no longer be banned from Wikipedia so at least
> he'll have something to do. Q.v. http://tinyurl.com/25y6y8

It is a shame that you so easily toss aside his many contributions to
this community. I hope you didn't mean to be as snide as the language in
the statement above conveys.

The link to the Wikipedia ban is helpful, though. It is what I would
have expected to see prior to Andy's 18 month ban.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: RDFa Basics in 8 minutes (video)
http://blog.digitalbazaar.com/2008/01/07/rdfa-basics/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Unjust banning of Andy Mabbett

[Manu Sporny]

I just got back from vacation, otherwise this would have gone out
sooner. It has come to my attention that Andy Mabbett has been banned by
the admins for 18 months[1].

This is an unjust punishment, especially considering that he is one of
the largest contributors to our community. Rather than make sweeping
assertions and accusations, I'm going to back this post up with hard
data. Here are the statements that will be addressed:

- Andy is one of our most prolific contributors, this community will be
  harmed by such a long-term ban.
- An 18 month ban does not fit Andy's behavior - it is an unjust
  punishment.
- Andy was tried as guilty, without complete documentation.
- Andy pushes the limits in this community, and because of him, we know
  what is and is not acceptable in this community.
- Andy says what some of the rest of us are thinking, and he shouldn't
  be banned for such an extreme length of time for voicing his opinion.

Andy is one of our most prolific contributors
-

Maybe most of you are unaware of Andy's contributions to this community.
I took the time to write a script to download and analyze the entire
history on Microformats.org's mailing lists (the script is attached to
this e-mail). Here are the top contributors to the microformats-discuss
mailing list:

andy mabbett - 1133 posts - 9.68% of contributions
   ryan king - 885  posts - 7.56% of contributions
tantek celik - 833  posts - 7.11% of contributions
scott reynen - 504  posts - 4.30% of contributions
  brian suda - 467  posts - 3.99% of contributions
 david janes - 432  posts - 3.69% of contributions
   chris messina - 388  posts - 3.31% of contributions
   charles krempeaux - 233  posts - 1.99% of contributions
   mike schinkel - 193  posts - 1.65% of contributions
 dr. ernie prabhakar - 188  posts - 1.61% of contributions
 danny ayers - 171  posts - 1.46% of contributions
 kevin marks - 145  posts - 1.24% of contributions
  ciaran mcnulty - 135  posts - 1.15% of contributions
frances berriman - 134  posts - 1.14% of contributions
ben ward - 126  posts - 1.08% of contributions
   bruce d'arcus - 120  posts - 1.02% of contributions
paul wilkins - 119  posts - 1.02% of contributions
 dimitri glazkov - 110  posts - 0.94% of contributions
   benjamin west - 107  posts - 0.91% of contributions

Here are the top-10 contributors to the microformats-new mailing list:

 manu sporny - 298 posts - 19.13% of contributions
   martin mcevoy - 238 posts - 15.28% of contributions
andy mabbett - 182 posts - 11.68% of contributions
scott reynen - 148 posts - 9.50% of contributions
  brian suda -  62 posts - 3.98% of contributions
tantek celik -  37 posts - 2.37% of contributions
 david janes -  36 posts - 2.31% of contributions
guillaume lebleu -  27 posts - 1.73% of contributions
frances berriman -  26 posts - 1.67% of contributions
  julian stahnke -  20 posts - 1.28% of contributions

It is quite evident from this data that Andy has produced more than
anyone else in this community, even assuming that 10% of the threads
that he starts result in a ban on his account. I know of no other
community that would treat one of their primary contributors in this manner.

An 18 month ban doesn't fit Andy's behavior
---

Banning somebody for 18 months is quite a serious amount of time, and
while the admins might not have come to the decision lightly, I do
question whether the punishment is justified. If you look at the
documented rules that were added/changed due to Andy[2], you will note
that a whopping 13 of the 17 are EDITORIAL rules. The other 4 are
behavioral rules that Andy has broken in the past (as have several
others on the mailing list). I am not defending bad behavior, just
noting that part of the reason that Andy is being banned is due to these
EDITORIAL rules that he has broken and I don't think that an 18 month
ban is justified for breaking editorial rules.

His behavior as of late has been much calmer and more respectful, so I
see no reason why this ban has appeared, seemingly out of the blue, at
this time.

Andy was tried as guilty, without complete documentation


There is still no documentation as to what Andy has done in the past to
warrant this type of ban. In the admin's post to the list, the following
was mentioned:

> As time permits, the admins will both hyperlink each of those
> annotations to the specific email in the archives or edit in the wiki
> history that caused it, as well as annotate any remaining rules with
> their causes as well.  We believe this will help provide better
> transparency and accountability.

The time to generate transparency and accoun

[uf-discuss] Sparqlbot - kinda like the computer on Star Trek

[Manu Sporny]

This has to be the coolest semantic web related thing I've seen this
year. Sparqlbot lets you load semantic data from various URLs and
perform SPARQL queries on them via IRC using natural language.

It understands hCard, there is an example of it being used in Twitter -
neat proof of concept.

The end result is something that resembles the ship computer from Star Trek.

--

* Now talking on #sparqlbot, on irc.freenode.net
* Topic for #sparqlbot is: sparqlbot noise, see
http://semsol.org/semcamp/sparqlbot for commands
* Topic for #sparqlbot set by bengee at Wed Feb 20 12:04:32 2008
* #sparqlbot :[freenode-info] if you need to send private messages,
please register: http://freenode.net/faq.shtml#privmsg
 sparqlbot, load http://rss.slashdot.org/Slashdot/slashdot
 221 triples loaded in 4.78 seconds
 sparqlbot, news about RIAA
 Leaked RIAA Training Video
(http://yro.slashdot.org/article.pl?sid=08/02/20/2317202&from=rss)
 hey manu. that was quick ;)
 :)
 try the geo stuff or picture as well
 yeah, wanted to try it out :)
 how do you use the geo stuff?
 omp, I'll show
 % Geonames-based location on Google map
 sparqlbot, geo-load Vienna
 35 triples loaded in 1.53 seconds
 so instead of Vienna you can use any name of a city, etc
 sparqlbot, where is Vienna
 Vienna is at 48.2084877601653, 16.3720750808716, view on
map: http://maps.google.com/maps?q=48.2084877601653,16.3720750808716
 wow
 that's awesome.
 it goes to Geonames, searches for 'Vienna' and the
lat/long is put into map
 next: Person
 % FOAF-based person's geo-home (location on Google map)
 sparqlbot, load http://sw-app.org/mic.xhtml
 41 triples loaded in 1.93 seconds
 note: that's RDFa ;)
 sparqlbot, mhausenblas's geo-home
 http://sw-app.org/mic.xhtml#i geo-home is at 47.064, 15.453,
view on map: http://maps.google.com/maps?q=47.064,15.453
 mhausenblas is my foaf:nick
* msporny's jaw is on the floor.
 you can also pull in from Twitter (has hCard)
 so, it understands hCard using GRDDL?
 yeah. bengee did really a great job with the bot!!!
 no doubt!
 not sure about how the µF is pulled in - bengee?
 via ARC extractors
 and thanks :)
 just updated the command UI
 do you have a demo of hCard being used? I'm going to send this
out to the uF community.
 the hcards from twitter work
 got an example?
 it's added as foaf:name
 hmm, but needs foaf:nick, too
 great! thankx bengee. wouldn't be URI be better for the
author?
 so, no pure hcard command yet I think
 I added both, for now :9
 dc:creator was simpler
 :)
* TedThibodeauJr ([EMAIL PROTECTED]) has joined #sparqlbot
 sparqlbot, load http://twitter.com/Scobleizer
 ah, damn you
 ;)
 :)
 1132 triples loaded in 20.3 seconds
 YES!
 sparqlbot, smush
 OK
 :(
 What does smush do?
 It sounds like all my triples are gone...
 sparqlbot, Scobleizer's contacts
 bengee, I found Mr Messina, missrogue, Scott Beale, Evan
Williams, Jack Dorsey, Biz Stone, sara, Krissy, Philip Kaplan, veen,
Jason Shellen, Sacca, Scott Fegette, Matt Galligan, Jerry Richardson,
danah, Brian Walsh, Clint G, Jim Williams, Paul Morriss, Colin
Schlüter, Ian Hay, Wayne Sutton, nanek, Ross, caroline, Hunter, Eric
Alba, Brad Barrish, necrodome, Mack D. Male, Nitin, om, Jason, Narendra,
steve epstein, Dave McClure, Brad Davis S
 smush consolidates bnodes
 so that you can do xfn queries (like the one above) by name
 bengee - this is the coolest thing I've seen this year.
 heh, thx
 sparqlbot, faq microformats
 bengee, see http://www.w3.org/2001/sw/SW-FAQ#relmf
 what I say all the time!
 bengee IS cool :)
 % Geonames-based pictures from flickr
 sparqlbot, geo-load Rome
 103 triples loaded in 3.71 seconds
 sparqlbot, pictures from Rome
 pictures from Rome at 41.9, 12.483, view via
flickrwrappr:
http://www4.wiwiss.fu-berlin.de/flickrwrappr/page/photosDepictingLocation/41.9/12.483/1

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: RDFa Basics in 8 minutes (video)
http://blog.digitalbazaar.com/2008/01/07/rdfa-basics/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Major change to microformat specs without prior discussion or notification

[Manu Sporny]

Thom Shannon wrote:
> perhaps there was prior discussion and agreement that was just a long
> time ago? Have you searched the archives or asked Tantek directly?

Here's the IRC log regarding the change to the wiki:

http://rbach.priv.at/Microformats/IRC/2008-02-07#T010220

I agree with the change - I don't agree with not running it past the
microformats-new list. It seems like a fairly far-reaching
change/update. It invalidates the need for "mfo" in hcard, doesn't it?
If it were applied to the rest of Microformats, it would invalidate the
need for "mfo" entirely.

There are logs - so it would be wrong to say the decision was made in
private, it was done on IRC, without notification to microformats-new.

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Andy Mabbett wrote:
> In message <[EMAIL PROTECTED]>, Manu Sporny
> <[EMAIL PROTECTED]> writes
> 
>>> It would be useful to have a
>>> more blanket term for instances where one person has multiple roles of
>>> that kind.
>>
>> You can always specify multiple 'role's in hCard to state that the
>> person had more than one role.
> 
> One cannot "always" specify such things, because the page content (e.g.
> "Beethoven's Fifth") does not always spell out such terms.

Right, point taken.

>>> I know you had a problem with it but if the role 'artist' is
>>> vague in so far as 'performer', 'composer' etc.. are concerned then
>>> perhaps it would be useful for exactly that reason. What do you think?
>>
>> I've got no problem adding more "contributor types" as convenience
>> classes for "composer", "performer", "publisher", "label", etc.
>> However, like all things Microformats - they've got to be backed up by
>> examples.
>>
>> The issue isn't "wouldn't these be really cool to have", but rather
>> "we need to demonstrate that there are enough of these on the web to
>> justify adding more terms to hAudio".
> 
> Like I said a day or two ago: "for the guidance of wise men and..."

Alright, wise-guy =P - put the terms that you would like included on the
haudio-issues wiki and let's start tracking them.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Robert O'Rourke wrote:
> Ah yes, so would you say 'performer', 'creator' and 'composer' are roles
> and not different to being a contributor? 

Yes, that is why 'contributor' was picked, rather than 'performer',
'creator', or 'composer'. :)

> It would be useful to have a
> more blanket term for instances where one person has multiple roles of
> that kind. 

You can always specify multiple 'role's in hCard to state that the
person had more than one role.

> I know you had a problem with it but if the role 'artist' is
> vague in so far as 'performer', 'composer' etc.. are concerned then
> perhaps it would be useful for exactly that reason. What do you think?

I've got no problem adding more "contributor types" as convenience
classes for "composer", "performer", "publisher", "label", etc. However,
like all things Microformats - they've got to be backed up by examples.

The issue isn't "wouldn't these be really cool to have", but rather "we
need to demonstrate that there are enough of these on the web to justify
adding more terms to hAudio".

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Alf Eaton wrote:
>> The example above is valid hAudio markup - is your issue with the word
>> "contributor" instead of "creator"?
> 
> Basically, yes :-) And it's not a huge issue, I was just wondering if
> there was justification for it being that way - which there is, it seems.

We're also tracking this issue on the hAudio issues page now (Issue #D1):

http://microformats.org/wiki/haudio-issues

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Andy Mabbett wrote:
> In message <[EMAIL PROTECTED]>, Manu Sporny
> <[EMAIL PROTECTED]> writes
> 
>> Why doesn't the following work for you, then?
>>
>> 
>>   Primal Scream -
>>   Screamadelica
>> 
>>
>> Per the hAudio spec, you have just marked up an album called
>> "Screamadelica", whose primary contributor (the artist) is "Primal
>> Scream".
>>
>> The example above is valid hAudio markup
> 
> I thought "fn" was required.

It isn't:

http://microformats.org/wiki/haudio#Album

You MUST use either FN or ALBUM, or both. In other words:

If you ONLY use FN - you are talking about an audio recording.
If you ONLY use ALBUM - you are talking about an audio album.
If you use BOTH FN and ALBUM - you are talking about an audio recording
from the specified audio album.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Alf Eaton wrote:
> It would work, but so would a number of very complicated things. My
> needs are essentially very simple:
> 
> Primal Scream - Screamadelica
> 
> so
> 
> Primal Scream -  class="album">Screamadelica

Why doesn't the following work for you, then?


   Primal Scream -
   Screamadelica


Per the hAudio spec, you have just marked up an album called
"Screamadelica", whose primary contributor (the artist) is "Primal Scream".

The example above is valid hAudio markup - is your issue with the word
"contributor" instead of "creator"?

> If there really "weren't enough examples that clearly listed anybody
> other than the creator", doesn't that make things easier?

Sorry, that was badly worded on my part. What I meant to express was:

There weren't enough examples that clearly showed that people were using
the word "artist", "label", not mentioning the role, or using
"publisher" more than the others. It was a mixed bag and what we saw at
the end was the chance to support all of these by using "contributor" in
the simple cases and contributor + hCard role in the complex cases.

None of this seems to be an issue with what you're trying to mark up,
though. If it is still an issue, could you please post some other data
that you're attempting to markup where the hAudio spec doesn't let you
mark it up in the way that you want to?

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Alf Eaton wrote:
> How about this:
> * All "contributors" played a role in the creation of the audio.
> * If there's one or more "creators", those entities played a primary role.

We looked at that approach, and found that we didn't have the examples
to back up the argument that we should make the distinction between
"creator" and "contributor" because there weren't enough examples that
clearly listed anybody other than the creator, and because hCard already
has a "role" field.

If you really want to make the distinction between a publisher, a
drummer, a singer, a technician, and someone else, you can always use an
hCard and utilize the "role" property[1].

> But then I'm struggling to think of actual examples where your rule
> wouldn't be enough (though having to list the main contributor at the
> start of the list might be one problem). It just feels wrong not to be
> able to explicitly mark the primary creator(s) when, as you say,
> sometimes you do want to do just that.

You can do this using "role" in hCard when describing the contributor.
If this doesn't work for you, you can use hCard RDFa which does
differentiate between the primary creator(s) and contributors.

> What if there are two primary creators (composer and performer, say) and
> the rest are just auxiliary contributors?

You could mark up each primary creator's "role" using hCard to describe
each creator. You could not specify the auxiliary contributors' roles,
or you could specify them - it's up to you to determine how specific you
want to be.

Does that work for your needs?

-- manu

[1]http://microformats.org/wiki/haudio#Contributor

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Andy Mabbett wrote:
> It seems strange that the microformat does not distinguish between the
> main "contributor" and others. 

It does - you list the main contributor first, if you care about that
sort of thing. Otherwise, you can list them in any order.

> Both the Beatles and Geoff Emerick
> "contributed" to "Sgt. Pepper's Lonely Hearts Club Band", for instance:
> 
>   
> 
> but one is clearly more significant than the other.

Sure - but what about this one:

http://music.yahoo.com/release/115057

Which one is more significant than the other - the label or the artist?
Are "creators" more important than "contributors"? These questions are
philosophical in nature - you can't assume that "creator" should be used
to note the significance of a contribution.

> There does seem to be a tendency in microformats, towards unduly low
> granularity; I find that strange.

Why do you find that strange? We're working with lowest common
denominator here. When you do that, you get low granularity.

> Although in classical music, the composer may be as-, or more-,
> prominent than the artist; likewise the conductor. Higher granularity
> would allow for such distinctions.

Sure - now all you have to do is find enough examples online, (we'll
need about 30 with the composer clearly denoted as well as the artist
with the composer more prominently displayed than the artist) for us to
make the argument for putting this feature into hAudio.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Andy Mabbett wrote:
> In message <[EMAIL PROTECTED]>, Manu Sporny
> <[EMAIL PROTECTED]> writes
> 
>> If only one contributor is listed, it is assumed that he/she/it is also
>> the creator of the hAudio. If multiple contributors are listed, it is
>> assumed that the first contributor is the creator, and all subsequent
>> contributors played supporting roles in the creation of the hAudio.
> 
> That fails as soon as we want to mark up something like:
> 
> Simon Rattle conducted the CBSO in a marvellous rendition of
> Beethoven's Fifth

Yes, the use of 'contributor' falls apart completely when we have markup
like that... which is uncommon.

You should have noted that markup such as that is an edge case. Look at
the audio-info-examples and you will be lucky if you find 1 or 2
instances of the markup you describe above.

My point is that it is easy to manufacture words that break hAudio - but
much harder to find actual examples online that break it.

If you have issues with this approach, you can always use hAudio RDFa,
which does make the distinction between "dc:creator" and
"dc:contributor". If you wanted to be even more specific, just include
the Music Ontology vocabulary and mark it up using that.

>> Thus, it can be said:
>>
>> Not all contributors are creators.
>> Not all contributors are artists.
> 
> That can certainly be said. However, it cannot be expressed in hAudio
> without requiring the publishers of such examples to re-order their
> content. It is a microformats "principle" to not do so.

For the publishers that need to re-order their content to mark up
hAudio, they are obviously stretching what hAudio uF can do, and should
use hAudio RDFa.

>> Thus, we should not narrow the "who made it?" behind hAudio down to
>> those more narrow categories.
> 
> Your conclusion is not supported by the forgoing claims.

Then does doing this support my conclusion:

*waves hands wildly in the air*

=P

More seriously:

We don't have enough examples to split "contributor" into "label",
"publisher", "creator", and "artist" - which is what the examples showed
to be the most prominently displayed contributors across the 93+ sites
that we analyzed for hAudio.

>>> It doesn't seem to be based on established practice, as from the
>>> overview it looks like existing markup overwhelming uses 'artist'.
>>> http://microformats.org/wiki/audio-info-brainstorming#artist
>> If we used artist, we would not have been able to mark up publishers,
>> composers, audio technicians, etc.
> 
> If we used *only* 'artist', perhaps, but not if we used 'artist' *AND*
> 'composer' + 'technician'.

There aren't enough examples that list the composer or the technician to
make the argument for adding those into hAudio. You're more than welcome
to go back through the audio-info-examples and re-analyze all of the
sites to prove your point, though.

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] haudio contributor

[Manu Sporny]

Alf Eaton wrote:
> I was looking at using haudio today, but stumbled on the 'contributor'
> field: is there a reason it's 'contributor' rather than 'creator', even
> for the main creator (artist, in music) of the piece of audio?

We decided to not use "creator" because it would not be the proper
semantic word for say, a publisher, or a composer. Most of the examples
that we came across listed the publisher as well as the band that
created the musical piece (CD). However, calling the publisher a
"creator" would not be semantically correct.

Dublin core makes this differentiation. There is a dc:creator field,
which is a narrower concept from dc:contributor. Microformats try to use
the most common subset of information among all examples. Some had
"artist", some had "publisher", some had "label", others had "band" -
these are all contributors.

hAudio allows for listing multiple contributors.

If only one contributor is listed, it is assumed that he/she/it is also
the creator of the hAudio. If multiple contributors are listed, it is
assumed that the first contributor is the creator, and all subsequent
contributors played supporting roles in the creation of the hAudio.

Thus, it can be said:

Not all contributors are creators.
Not all contributors are artists.

Thus, we should not narrow the "who made it?" behind hAudio down to
those more narrow categories.

> It doesn't seem to be based on established practice, as from the
> overview it looks like existing markup overwhelming uses 'artist'.
> http://microformats.org/wiki/audio-info-brainstorming#artist

If we used artist, we would not have been able to mark up publishers,
composers, audio technicians, etc.

Does that make sense? Does that explanation raise any further questions?

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Digg joins DataPortability Project (Microformats mentioned)

[Manu Sporny]

Tantek Çelik wrote:
> Manu you are correct, MicroID is *not* a microformat.  It did not follow the
> process, and violates numerous microformats principles.

I've been in contact with Steve Williams, Digg's Technical Lead for
Infrastructure Development, and he's been very open to discussion. We've
since cleared up the fact that MicroID is not a Microformat and I
explained a bit about the uF process. He was very open to discussing the
issue and has since fixed the blog entry:

http://blog.digg.com/?p=108

Steve got the impression that MicroID is a Microformat from the
microid.org blog, which states:

"MicroID: A Microformat for Digital Identity"

I have contacted Jeremie Miller and Peter Saint-Andre (authors for the
current MicroID IETF document) to politely let them know about the
differences between a Microformat and the work that they have done. I
have also invited them to put MicroID through the uF process or create
an RDFa vocabulary.

I'll let this list know when I have gotten a reply from them.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Intro to the Semantic Web in 6 minutes (video)
http://blog.digitalbazaar.com/2007/12/26/semantic-web-intro

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Dublin Core as a microformat

[Manu Sporny]

Andy Mabbett wrote:
> Note also that Dublin Core provides a range of pre-existing
> vocabularies, which might e re-usable (without the dc. prefix) where
> names are needed for classes in other microformats. For example, the DC
> type "sound" might be useful at the lowest level of hAudio

Not to mention hAudio could also use DC.title instead of FN... or
DC.creator/DC.contributor instead of CONTRIBUTOR, or DC.date instead of
PUBLISHED, and DC.description instead of DESCRIPTION.

I've never been happy with the choice of FN instead of TITLE in hAudio
(TITLE means "job title" in Microformats). This could offer a good
compromise if people are interested?

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Digg joins DataPortability Project (Microformats mentioned)

[Manu Sporny]

Digg has joined the DataPortability[1] Project:

http://blog.digg.com/?p=108

>From the piece:

"Just this week, we added MicroID, a Microformat that lets you prove to
other services that you own your Digg user profile."

Since when was "MicroID" a Microformat? Reading through the spec, it
does some very non-microformatty things:

5

It's great that they're doing the whole data portability thing, but
looks like they're not quite sure about the details yet? Anyone know
anybody at Digg that could shed some light on where they're going with
all of this?

-- manu

[1] http://www.dataportability.org/

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Intro to the Semantic Web in 6 minutes (video)
http://blog.digitalbazaar.com/2007/12/26/semantic-web-intro

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Firefox 3 (was: Icons of MF wiki)

[Manu Sporny]

Andy Mabbett wrote:
> In message <[EMAIL PROTECTED]>, Michael
> Smethurst <[EMAIL PROTECTED]> writes
> 
>> On 11/1/08 10:31, "Alex Faaborg" <[EMAIL PROTECTED]> wrote:
>>
 do you have any plans to support rdf-a in the
 interface? In 4.0, 5.0, 6.0?
>>>
>>> We haven't decided yet, and I would love to hear people's opinions
>>> both in favor of and against including RDFa support in a future
>>> release of Firefox.
>>
>> +10 for me and my colleagues
> 
> I have ~50,000 colleagues. Available to the highest bidder ;-)

Could you, perhaps, get some of them to start analyzing websites[1] for
us :)

-- manu

[1]http://microformats.org/wiki/video-info-examples#Video_Sites_Needing_Analysis

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Firefox 3 (was: Icons of MF wiki)

[Manu Sporny]

Michael Smethurst wrote:
> On 11/1/08 10:31, "Alex Faaborg" <[EMAIL PROTECTED]> wrote:
> 
>>> do you have any plans to support rdf-a in the
>>> interface? In 4.0, 5.0, 6.0?
>> We haven't decided yet, and I would love to hear people's opinions
>> both in favor of and against including RDFa support in a future
>> release of Firefox.

+1 for me. +1 for our company.

It would be a real shame if only one way of extracting semantics from a
web page were supported in Firefox. If Firefox is serious about the
semantic web, it would be nice to see support for all the methods of
expressing semantics on web pages.

Note the recent proposal on creating a unified representation for
semantic objects (uF, RDFa, eRDF):

http://microformats.org/discuss/mail/microformats-dev/2008-January/000410.html

This would make it much easier for Firefox to support semantics in
pages. It isn't technically difficult to support all of them, so I see
no reason not to do so.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] RDFa Basics video (8 minutes)

[Manu Sporny]

Guillaume Lebleu wrote:
> Manu Sporny wrote:
>> Constructive feedback would be great, as I'll probably be doing the
>> "advanced" RDFa tutorial in a month or so, and will need to know what
>> worked and what didn't in the RDFa Basics video.
>>   
> I'm relatively new to RDFa and this is a great introduction. I'm
> probably going to say things you've already heard, so please bear with me.

Any feedback is really appreciated, so I thank you for taking the time
to write out your thoughts on the video[1] :)

> So, when comparing uf and RDFa, adopting RDFa seems a
> huge leap of faith and a lot of work considering it requires XHTML 2.0

Ooops, looks like my post lead to some confusion. RDFa works with any
version of XHTML. You can write valid RDFa today. t's not an "it's going
to happen in the future" thing - you can author RDFa today (for example,
Operator already has RDFa support).

> and your introduction does not mention any application supporting RDFa...

That's true, there aren't many applications that use RDFa today...
mostly because the standard is just being finalized. The semantic web
stuff has been brewing in academia for almost a decade. We have the
Microformats community to thank for getting the message about why
semantics are important in web pages... so, I think that we're really at
the cusp of this stuff taking off.

> So, if the goal of this video is to evangelize RDFa to a large audience,

Hmm... the goal of the video wasn't necessarily to evangelize RDFa - it
was to educate web developers about some basic semantic web concepts. It
was supposed to teach people very briefly about the power of RDF, what a
CURIE is, what N3 notation is, and how you can express semantic
information in XHTML web pages using RDFa. Do you think it achieved that
goal, or did it fall short for some reason? Was there too much going on
in each part of the video?

> I think it would be great to explain why (ex. why id, class and
> a/href/rel haven't been leveraged more to represent RDF triples)

[FULL DISCLOSURE: I am on the W3C RDFa task force... take what I have ]
[ to say with a grain of salt.]

I'll explain here, just so you know. I don't know how many people know
this, but XHTML is extensible in that you can add modules to extend
XHTML. These modules define new attributes and tags that can be used in
a valid XHTML document. RDFa is an extension to XHTML, and works with
all current browsers that support XHTML.

@id isn't used because it must be unique to a page. It also already had
a different set of semantics associated with it in XHTML and it doesn't
allow CURIEs, AFAIK. @about is used instead.

@class wasn't used because they didn't want to stomp on the Microformats
community's implementation, among other reasons. In certain RDFa
implementations, bad things happened when you mixed RDFa and
Microformats on the same page. @about is used instead.

@href and @rel were re-used. @href is used to denote a object, while
@rel is used to denote predicates.

The current implementation makes sure to take the semantics of the
pre-existing XHTML standard into account, the following attributes were
used from XHTML:

@rel, @rev, @href, @src

These attributes were added in XHTML+RDFa:

@about, @instanceof, @resource, @property, @datatype, @content

I should mention that while RDFa may seem more complex than Microformats
(and in some cases it is)... there are no issues with ABBR or @title
mis-use/abuse. These endless debates we seem to have over "where do we
place the ISO machine readable data in the Microformat?", are a
non-issue in RDFa.

> also explain how an implementation can best leverage the
> backward-compatibility/evolutionary benefits of microformats with the
> RDFa more formalist and consistency with other w3 standards.

Thanks for the suggestion - I'll try to put that in the next video, or a
video comparing/contrasting Microformats and RDFa. We need both... like
any syntax, each has its benefits and drawbacks.

> Last, if you believe like me that applications drive standards, not the
> reverse, then I think what will ultimately get people excited is to have
> a demonstration of how this content can be leveraged by an application
> once published and gathered in a RDF store. 

You're right, the proof of the greatness of any technology is in it's
adoption rate and the number of applications that are written using that
technology.

> if I had to evangelize RDFa, I would
> start with the application, for instance showing content in a browser,
> then showing how it's possible to type queries against this content in a
> browser plugin. Then only I would show the implementation, and at the
> end possibly, adoption numbers such as how many people have downlo

[uf-discuss] RDFa Basics video (8 minutes)

[Manu Sporny]

Finished an RDFa Basics video this weekend. It attempts to explain RDF,
CURIEs, N3 and basic RDFa in 8 minutes:

http://www.youtube.com/watch?v=ldl0m-5zLz4

Thought some of you would want to learn about some of the upcoming
features of XHTML2 as well as compare and contrast how RDFa differs from
Microformats.

Constructive feedback would be great, as I'll probably be doing the
"advanced" RDFa tutorial in a month or so, and will need to know what
worked and what didn't in the RDFa Basics video.

A high-bitrate version, along with all source material, will be uploaded
and put on the Digital Bazaar wiki tomorrow:

http://wiki.digitalbazaar.com/en/rdfa-basics

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Intro to semantic web (video)

[Manu Sporny]

Happy Holidays, all :)

I've had a hard time explaining what the semantic web is about in a
concise manner over the past several months, so I decided to focus on
answering that for people that don't really know much about the web.

I spent the last couple of days playing around with the video creation
suites in Linux (Blender, Cinelerra, Gimp, xvidcap and a borrowed wacom
tablet).

Here's the result of a couple of hours of mucking about - does this
explain what the semantic web is all about? Is it simple enough? Too
simple? Too long? Too short?

http://www.youtube.com/watch?v=OGg8A2zfWKg

The entire thing, including all source material, is under a Creative
Commons Attribution-Share-Alike license (including remixing and
distribution). All source material is available here:

http://wiki.digitalbazaar.com/en/semantic-web-intro

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Benjamin Hawkes-Lewis wrote:
>> 
>> http://www.w3.org/TR/html401/struct/global.html#adef-title
>>
>> title = text [CS]
>> This attribute offers advisory information about the element for
>> which it is set.
>> 
>>
>> However, I do agree that "PT2M23S" is stretching the rules a bit.
> 
> Can information that "readers are probably not going to understand" be
> classed as "advisory"?

We could argue it both ways based on how we define "advisory" and the
pattern recognition and cognitive abilities of the general Internet
population. Since we have a potentially better solution on the table,
let's not go down this path yet.

> What I was proposing was this. When all the information required is
> available in the content of the element in Arabic numeral form, and all
> a parser would need to know is what units are being used, we should
> prefer to mark up the units rather than attempt hide an ISO format of
> the same data with the TITLE hack.

Agreed.

> So, to adopt your milliseconds example, we could avoid TITLE and just use:
> 
> 2
> milliseconds

Sure, we could do that... although, we should be careful to address all
of the problems... we would still need to address some of the
non-standard cases that you outline below.

> We might prefer to specify abbreviations like s and ms, I'm not sure.

If we're going to put "s" and "ms" in @class, then I don't think that
would be a good idea. If we were to, however, place that information in
title... that would be fine, IMHO. To illustrate:

This would be a bad idea:
3 seconds

This would be acceptable:
3 seconds

Or if we wanted to use the hMeasurement approach:
three seconds
two minutes, three
 seconds
two years, 35 hours
three seconds

> Obviously, if this principle were to be extended to other sorts of
> measurements, it could get more complicated for two reasons:

Take a look at the hMeasurement strawman... there's been a great deal of
thought put into the issues that you describe:

http://microformats.org/wiki/measure-brainstorming#Straw_man

> 1. People might want to use variations on the SI units that cannot be
> expressed with the SI prefixes e.g. 10^26 s.

We can do this if we use hMeasurement:

10^26 seconds.

> 2. People might want to use non-SI, non-global units like inches and
> quarts.

Then they will need to convert it to SI units:

15 stones

> Now, it might be that we could adapt the principle to serve in some of
> those situations too:
> 
> 1. Perhaps we could allow class names like "seconds/10^26" (it's ugly
> but legible and conforming).

We can already do this in hMeasurement:

10^26 seconds

Or, alternatively they could convert it to another representation format:

10^26 seconds

> 2. Perhaps we could think about specifying class names for widely-used,
> non-SI units like inches.

Like this (in the current hMeasurement proposal):

four feet, four inches

> 1. Obscure units ("5 chains wide")

Boiling the oceans - we should make them convert it into a more popular
measurement.

> 2. Use of non-Arabic numerals ("III HORA")

Boiling the oceans - make them convert it into a more popular measurement.

> 3. Use of words instead of digits ("three seconds long")

I think addressing this was outlined above.

> 4. Fuzzy representations where not all the information required is
> implicit in the human-friendly content ("about three miles")

There is room for error metrics in hMeasurement too, although, it hasn't
been worked out quite how we do that.

> For these cases, we would /still/ need an expansion pattern. I wasn't
> particularly thinking of the expansion pattern you suggest, since it's
> still attempting to put tortured data-showing requirements over the
> needs of human end-users.

Do SI measurements constitute "tortured data"? Is displaying "2min 23s",
or "2 minutes 23 seconds" better than displaying "PT2M23S"?

> The point of my suggestion is to reduce the number of cases where we
> need an expansion pattern, since expansion patterns are proving
> problematic.

Let's address the actual problem of precise expansion patterns for
measurements.

So we could do one of the following:

1. Use hMeasurement and add "h for hours" and "y for years".
2. Define "second", "minute", "hour", "year" classes.
3. Create "second", "minute", "hour", and "year" aliases in to the
   hMeasurement units "s", "min", "h", and "y", respectively. Use
   hMeasurement.

I suggest doing the 3rd thing, which would give us all of the following,
valid, markup:

2 minutes 23 seconds
2:23
2 minutes, 23 seconds
2:23

This approach is more of a measurement design-pattern, but solves the
accessibility and usability issues surrounding using ISO8601 and a
variety of the other ISO formats for measurement.

-- manu
___
microformats-discuss mailing list
microformats-di

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Paul Wilkins wrote:
> On Dec 17, 2007 2:38 PM, Manu Sporny <[EMAIL PROTECTED]> wrote:
>> By constricting DURATION to have a restrictive format, HH:MM:SS, we are
>> being short-sighted and are not thinking about the other Microformats
>> that are still to come that will need to specify DURATION.
>>
>> "00:02:23" is being shortsighted. Let's learn from our past and not make
>> the same mistake again... let's not be short-sighted about this decision.
> 
> If we stay with "PT2M23S" then how are we going to deal with the title
> attribute issues.

We have some suitable candidates for replacement... all of them are not
ideal, so we are going to have to compromise. We know the following:

1. Using DURATION with ABBR was a compromise, so it's not like we're
   replacing something that is perfect.
2. Hidden data is considered harmful by the Microformats
   community.  == bad
3. Semantically abusing tags is considered bad by the community.

> I consider the following to be bad
> 2:23

Agreed. This is hiding data.

> Next we have the classical abbr-include-pattern.
> 
> This has issues in that the title is not an acceptable abbreviation of
> 2:23. The title text must be sensible to the human viewer.
> 2:23

Agreed. This is abusing the semantic meaning of ABBR.

> Then there's the SPAN element. This one too has issues with the title
> text, in that anybody seeing it isn't likely to understand its
> meaning.
> 2:23
> It appears that when the title text is used on content, it must must
> remain as a human-understandable construct.

Agree with the first part, readers are probably not going to understand
PT2M23S. Disagree with the last statement, this is not in violation of
the HTML spec, IMHO:


http://www.w3.org/TR/html401/struct/global.html#adef-title

title = text [CS]
This attribute offers advisory information about the element for
which it is set.


However, I do agree that "PT2M23S" is stretching the rules a bit.

> The SPAN element however has classically been allowed to be empty, as
> a placeholder for the likes of css images.
> This situation can be leveraged to provide computer data, without
> interfering with the content itself.
> 
> I consider the following to be less bad than the others above.
> 2:23

Agreed. I personally don't have a problem with hidden data like this,
especially when there are tools like Operator that can be used to check
your work. However, there are others in the community that will fight
you (and me) on this.

Just to go back to a previous e-mail in the day... I don't think I fully
understood what Benjamin was proposing with the following:


   2:25


After looking at it again and running it through a variety of tests,
it's looking like a fairly good solution to the issue... very verbose,
but it doesn't have any of the previously stated problems
(accessibility, usability, or tag abuse), and there are several more
benefits that it brings. For example, you can do this:


   twominutes and
   43 seconds


For an example of how this looks, check out #6 on the following page:

http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html

You can also do stuff like this, for fractional elements:


   2 milliseconds


In fact, if we had the following Microformat:

duration
  year
  month
  day
  hour
  minute
  second

We could address not only duration, but also specify time (January 15th,
2008):


   January
   15th,
   2008


This line of reasoning follows what we've been doing with hMeasure:

http://microformats.org/wiki/measure-brainstorming#Straw_man

Was this what you were getting at, Benjamin?

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Benjamin Hawkes-Lewis wrote:
> Here's another question that needs asking. How much real-world value
> does the use of the ISO standard for date time representations
> actually add in this /particular/ case (hAudio duration)?
> How often do these reasons apply to hAudio duration?

These questions are dangerously short-sighted, focusing on just hAudio
will hurt the Microformats community in the long run... I'll explain why
below.

> The impression I get is that the majority of cases would be served
> fine by:
>
> 2: class="s">25

This would be a giant pain to author, IMHO. Then again, it fixes our
accessibility/usability issues - placing much of the load on the
authors. If we make it this verbose to mark up this sort of information,
do we think authors are going to mark up DURATION?

For sites like ours that are automated, we would have no problem
adopting the approach listed above... but think about the blog author
that has to mark up DURATION. Are they going to take the time, or skip it?

What happens when somebody wants to specify a time duration as
"twenty-three minutes"? Or a measurement as "two stones"? Your proposal
above doesn't solve those problems.

Andy Mabbett wrote:
> On Sun, December 16, 2007 19:14, Manu Sporny wrote:
>> Paul Wilkins wrote:
>>
>>> Another possible solution is to provide greater detail for the time
>>> itself.
>>>
>>> 2:23
> 
>> If you are suggesting that we use the hh:mm:ss time format for
>> expressing duration, we cannot. That would be an abuse of the ISO 8601
>> standard.
> 
> We can, becasue we are not mandated to use the ISO 8601 standard.

So assume that we do that today...

We're locking in DURATION to have a very specific meaning "a length of
time". To denote that length of time, you have hours, minutes and
seconds HH:MM:SS.

Some time further down the line, somebody has another Microformat that
needs to specify a time duration. Their time durations, however, are in
years.

The problem comes in when the second person wants to denote their time
duration in years. We've already said that DURATION is "a length of
time" and specified a format HH:MM:SS. So now, authors have to translate
years into hours... quite a pain, but it gets worse.

Later yet, in a future Microformat far, far away, somebody comes along
and wants to specify time in fractions of a second.

Once again, they can't use DURATION because there is no space for
fractions of a second (which you can specify in ISO8601).

Remember, this same thing happened with the TITLE tag in Microformats.
TITLE is used to specify "a job title" in hCard. This meant that we
couldn't use TITLE in hAudio because it meant "a job title", not "the
title of an object, such as, but not limited to, a book, movie, album,
or person".

By constricting DURATION to have a restrictive format, HH:MM:SS, we are
being short-sighted and are not thinking about the other Microformats
that are still to come that will need to specify DURATION.

"00:02:23" is being shortsighted. Let's learn from our past and not make
the same mistake again... let's not be short-sighted about this decision.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Paul Wilkins wrote:
> 2:23
> 
> With this it is not possible to prevent the title from being used by
> screen readers and other people who hover their mouse over the time
> value.

This is not true. You can set several, of not all, screen readers to not
read titles of SPAN elements.

It is important for us to focus on the reason this discussion started in
the first place:

http://microformats.org/discuss/mail/microformats-discuss/2007-December/011035.html

The issue was accessibility, specifically, how accessible is the ABBR
design pattern for those that use screen readers.

At this point, it's really just a matter of testing the examples we have
so far:

http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html

Against the list of screen reader packages on the market:

http://en.wikipedia.org/wiki/List_of_screen_readers

I'll volunteer to check out Orca and JAWS and report the findings to the
list, and document them in the wiki.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Paul Wilkins wrote:
> Another possible solution is to provide greater detail for the time itself.
> 
> 2:23
> 
> This I understand is an acceptable title for screen readers, it
> expands suitably on 2:23 (which could be 2 hours 23 minutes or 2
> minutes 23 seconds) and it's computer understandable in an ISO 8601
> manner.

If you are suggesting that we use the hh:mm:ss time format for
expressing duration, we cannot. That would be an abuse of the ISO 8601
standard. The standard is very specific about specifying TIME and about
specifying DURATION. Duration MUST be in one of the following formats,
where 0-values can be omitted:

PnnYnnMnnDTnnHnnMnnS
PnnYnnWnnDTnnHnnMnnS
PT

This is correct for a duration of 2 minutes, 23 seconds: PT2M23S
This is not: 00:02:23

Here's what the various approaches thus far look like when you put them
on an HTML page:

http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html

There are really two questions that we're attempting to answer here:

1. Can we make screen readers not read the @title, of whatever element
   we choose, out loud?
2. Do we care that "PT2M23S" will appear if the person browsing hovers
   their cursor over the text denoting the duration, if that is the only
   way we can successfully utilize ISO standards in the Microformats
   community?

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Paul Wilkins wrote:
> The hAudio time should be denoted in seconds. If 3:23 is given it's to
> be seen as three minutes and twenty two seconds. If hours are needed
> it should be 1:3:23 (0 prefix optional) to denote 1 hour three minutes
> and twenty two seconds.
> 
> This way the hAudio standard can work without needing to modify the
> text, the abbr pattern isn't required and everybody can go home and
> sleep restfully for the night.

You may sleep restfully with that approach, but I can't imagine that
many others on here would... :)

You are effectively making the argument that we should forget about
using ISO standards, which is one of the microformats principles -
re-use, and replace it with our own.

I can guarantee you that if we take that approach, we'll be having this
same argument with the next ISO standard that gets used by the uF community.

I'm not stating that the solution we have for hAudio at the moment is
ideal, but re-inventing the wheel isn't necessarily the best approach
either.

What was the problem with the SPAN approach, again?

3:23

- You can set most, if not all, screen readers to not verbalize @title
  in SPAN.
- We're not abusing ABBR.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: [uf-new] Mapping Microformats to RDFa

[Manu Sporny]

Brian Suda wrote:
> Also, there is the same discussion on going on the RDFa mailing list:
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0113.html
> 
> As Ivan Herman replied on that list, GRDDL handles much of what you
> are looking for as well and much of those Microformats -> RDF
> conversions already exist.

Great! Where are they? Are the transformations only available as XSL
stylesheets? If so, they're not very useful as a quick-reference for
publishers... are they?

Are you talking about this:

http://esw.w3.org/topic/CustomRdfDialects

In which case:

The hcard2rdf.xsl is licensed under CC-non-commercial, which makes it
useless to any company wanting to implement this stuff in their products.

hreview2rdfxml.xsl is a 404.

There are no mappings for hCalendar, hAtom, or hResume, etc... what am I
missing? Apologies - I'm not that familiar with GRDDL tools that are
available... do you have some good links to GRDDL tools?

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Firefox 3 Javascript Semantic Data UI Control (was: Microformats and Firefox 3)

[Manu Sporny]

Dimitri Glazkov wrote:
> I really like the idea of allowing additional control over
> presentation via pseudo-classes, but I am worried that :target isn't
> quite right, at least if we follow the spec to the letter
> (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically
> since this pseudo-class is not dynamic and there may or may not be a
> fragment identifier on the microformat.

There is another option available. Songbird has released a specification
for a Javascript object that can be used to control some of the
functionality in the browser.

http://developer.songbirdnest.com/documentation/trunk/webpageapi/files/sbIRemotePlayer-idl.html

Operator/Firefox could provide something along the same lines to allow
publishers to disable the browser UI and provide their own via CSS.

Here's how it could work:

The SemanticDataUI object would be accessible, from Javascript, using
the “semanticDataUI” global variable attached to the currently loaded
document. A publisher could disable the semantic data UI in any browser
by running the following line of Javascript:

semanticDataUI.disableUI();

Users could control whether or not they allow web pages to disable the
Semantic Data UI. Most would probably allow web pages to disable the
semantic data UI.

Publishers could manually disable the Semantic Data UI and use CSS to
mark up their hCards, hCalendars, and hAudios.

This would give cross-browser UI control to both the users and the
publishers without having to do any CSS magic.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats and Firefox 3

[Manu Sporny]

Dimitri Glazkov wrote:
> This is not particularly transient, but it addresses #2, methinks:
> 
> http://glazkov.com/blog/margin-marks/

Mike, Alex - I think you should take a very serious look at Dimitri's
Margin Marks idea. Check out the screen mock-ups here:

http://flickr.com/photos/dglazkov/sets/72157601860335196/

Implementation would be a bit of a headache, but he has proposed a very
elegant solution on, IMHO, the right way to display semantic data items
on a web page. It is the best approach that I've seen so far, over all
of the UI concepts for Microformats in Firefox 3.

This is the same way that Eclipse shows the developer warnings, comments
and errors via the code editor. It would do well as a transient UI AND
wouldn't be intrusive on the browsing experience when the UI is active.
Exciting stuff...

-- manu

-- 
Manu Sporny
http://wiki.digitalbazaar.com/en/haudio-case-study

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Need for plain-language intros for each microformat

[Manu Sporny]

Andy Mabbett wrote:
> I think it's time we moved the specs to *-spec or *-specification, and
> used the "root" page for each microformat, such as the above, for a
> plain-language introduction, taking care to avoid jargon as much as
> possible.

+1 for this idea. There have been several times where I've pointed
somebody to a uF specification page to give them an overview and they
just come back claiming that the page didn't really tell them
anything... or worse, it confused them.

> 

The page should be a short introduction and shouldn't overwhelm the
reader. Perhaps a 1-2 paragraph introduction, a very simple example, and
links to other wiki pages at the bottom with more information.

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats UI in Firefox 3

[Manu Sporny]

Manu Sporny wrote:
> Here are some other examples:
> 
> action://map/find/eiffel-tower
> action://

Sorry, here are the other examples:

action://location/find/eiffel-tower
action://license/fulltext/Harry-Potter-and-the-Order-of-the-Phoenix
action://feed/subscribe/cool-hatom-feed
action://audio/play/haudio-punk-rock-song
action://resume/findjob/my-hresume

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Microformats UI in Firefox 3

[Manu Sporny]

Alex Faaborg wrote:
> Yes, while previous Firefox designs have focused on the browser
> injecting UI into the page, this discussion is about how the content
> creator should provide links and buttons for acting on microformatted
> content.

I'm probably being a bit dense, but it looks like we're entering into a
philosophical debate. Without taking sides, it looks like the
philosophical rift is this:

Side A: Publishers should be able to specify UI elements for their
Microformatted content in their HTML.

Side B: The browser should be solely responsible for injecting UI into
the page?

This debate has been tracked on the wiki:

http://microformats.org/wiki/audio-info-issues#Historical:_Graphic_buttons_in_rel-patterns

The current resolution is to leave implementation for user actions up to
the browser and uF plug-ins. Without going into the nasty details, which
are fully documented on the wiki, there is opposition to directly
specifying UI through uF markup. Microformats are about data, not UI.

That being said, if there is a desire to add generic UI actions to any
sort of semantic data (keep in mind eRDF and RDFa), the one idea that
seems to be most compatible with "Microformats are about data" but able
to give the publishers of any semantic data some control over the UI is
the "uf:// protocol idea".

Perhaps a generic set of "actions" that are defined by all semantic data
communities (uF, eRDF, RDFa, etc.). The assumption is that some sort of
ID mechanism is utilized. So for data like this:

...

Something like the following:

Add to address book
E-mail Alex

Here are some other examples:

action://map/find/eiffel-tower
action://

The above mechanism would allow people to specify default behaviors for
actions. Some could specify that "action://map/" is handled by Yahoo
Maps, while others might choose Google Maps or Microsoft Streets and Trips.

It is important that the Firefox developers not only think of
Microformats, but eRDF, RDFa, and other semantic markup technologies
that are coming down the pipeline.

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Re: Getting legal help (was: inappropriate behaviour)

[Manu Sporny]

Scott Reynen wrote:
> The microformats admins have decided to ban Andy Mabbet from this
> community (both email lists and wiki) for one week, due to continued
> failure to adhere to the "be nice" guideline [1] after a private warning.

I don't condone Andy's tone when replying to the thread that started all
of this. I think it is important to note that he is one of the more
frequent contributors to this community and constantly challenges the
ideas and concepts that are just accepted around here without explanation.

While I don't always agree with Andy, he does have a knack for making
logically sound arguments. It is vital to have people that can challenge
the status quo, people such as Andy, involved in a community such as this.

His replies reflect reservations that several members of this community
choose not to express out of fear of retaliation. In this case the topic
is: the insistence that we should not raise legal matters on the mailing
list.

The reasoning for not discussing legal matters on the list is not clear.
It is ironic that in an open community, such as this, that we have any
taboo topics... but here we are.

The only attempt at explaining this why we cannot speak about legal
matters is that nobody on here is a legal expert, including the admins.
If that is the case, I think there is something that we can do to solve
that issue.

I propose that we get the Electronic Frontier Foundation involved. If
not the EFF, then Creative Commons. Each of those organizations believe
in the open exchange of information and have lawyers on the payroll.

I volunteer to get the ball rolling if necessary. Thoughts and suggestions?

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Mediawiki accesskey shortcut usage instructions

[Manu Sporny]

Paul Wilkins wrote:
> From: "Andy Mabbett" <[EMAIL PROTECTED]>
>> Paul Wilkins <[EMAIL PROTECTED]> writes
>>> It could be a lot better if it said
>>> "Accesskeys differ according to your browser." which links off to a
>>> page that explains about Accesskeys, followed by "use ACCESSKEY S to
>>> save"
>>
>> It would be better still to say nothing. We don't say "move your mouse
>> pointer here and press the button to go to the page about..."

Can we please kill this thread? It's a humble request.

The signal to noise at this point is horrible. I don't think anybody on
here joined the list to discuss access key issues on our wiki.

Please discuss it among yourselves off-list if you must. Again - just a
humble request to stop spamming the list with access key issues.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Voluntary Public Domain declarations now enabled on the wiki

[Manu Sporny]

Rohit Khare wrote:
> Migrating to  a new, clearer copyright regime will not happen overnight
> and must be done clearly and cleanly -- but it begins, I submit, by
> offering to cooperate in the construction of a new regime. Please
> consider joining in by adding the release to you user profiles today...

Rohit, thank you for taking the time to put this together. It is not
only a good start, but demonstrates that key individuals in the
Microformats community are not attempting to do anything nefarious or
shady with what the community produces (like what happened in the case
of XMCD/CDDB).

If you would like to see who has signed up for voluntary public domain
release of their contributions, here's the list:

http://microformats.org/wiki/Category:public_domain_license

We are currently trying to put the hAudio draft into the public domain.

>From a legal standpoint, we would need everybody that made contributions
to that document to not only place the public domain template onto their
user pages, but also explicitly release their past contributions as
public domain works (since they still hold the copyright on the material).

The wording of the current template isn't explicit about past
contributions. The statement could be interpreted as "all future
contributions" since most legal statements are not retroactive unless
explicitly stated.  Please consider adding "retroactively" or "all past,
present and future contributions" to the text. Here is the public domain
agreement with the added changes:

I agree to release my past, present and future text and image
contributions into the public domain
http://en.wikipedia.org/wiki/public_domain). Please be aware that other
contributors might not do the same, so if you want to use pages with my
contributions under public domain terms, please check the other
contributors' user pages. If I do not desire to release my contributions
to the public domain, I will clearly note the copyright policy that
should be used with my contribution.

If this change is not made, we will have to perform the arduous task of
asking every author that contributed to a page to release their
copyright on that page. I have started this process with hAudio, where
we have asked every author of the draft page to release their edits into
the public domain:

http://microformats.org/wiki/audio-info-proposal#Public_Domain_Release

Thoughts and direction in converting old pages would be very welcome.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Microformats gets strong showing in Firefox 3 UI

[Manu Sporny]

Things can still change, but after talking a bit with the Firefox 3
folks - Microformats are starting to look more and more like they're
going to be supported in a big way in the next major release of the browser.

http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] video-metadata-models

[Manu Sporny]

Andy Mabbett wrote:
> /video-metadata-models
> /microshow

That's incredibly strange - both of these links appear under the
"Related" and "See Also" sections of those pages. Should red-link items
 be placed under each of those sections? There isn't anything at the end
of the links to "relate" to or "see"?

The media-info examples page is the only one that is current. I see no
reason to keep blank pages attached to abandoned/out-of-date initiatives
around, especially since these red links are over 2 years old.
Especially since there is no information that is being destroyed.

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Legal implications of using Microformats

[Manu Sporny]

M. Jackson Wilkinson wrote:
> If a patent were granted, then the holders could approach users of the
> now-patented "process" and hold them accountable for royalties and
> licensing fees.  All of a sudden, anyone from Microsoft to your small
> business can be threatened with, at minimum, a long legal battle.

Exactly the point - the Microformats community is not doing enough to
protect the implementors of their technology.

> This fear can be soothed fairly simply by releasing all work on the wiki
> into the public domain, or something of the sort.  All wiki pages could
> be under the LGPL, the GDL, or some other open licenses if not in the
> public domain.  There are several options here.

Right on the money, again.

> The challenge now is that every editor of the wiki would, I believe,
> need to either approve of the change in license, or their work would
> need to be stripped out of the wiki.  This kind of process has happened
> several times in open source software projects.  The microformats wiki
> may be sufficiently young as to make this somewhat possible, but it
> would certainly involve significant effort.
>
> It's one of those things that really needs to be handled right at the
> beginning.

Another brilliant statement! Deal with the problem now while it is
manageable - or later, when there are going to be multi-million dollar
lawsuits being bandied about. The Microformats community WILL be blamed
for not performing proper due diligence before placing their standards
online.

> Again, this is all just based on my personal experience and research,
> and is not legal advice, but may be useful as a way of understanding why
> some may be concerned.

The reason this issue was raised was because we have authored and filed
several patents and know what we are talking about regarding the dangers
of submarine patents. If you want an "official" letter from a legal firm
specializing in copyright and patent law, stating how tenuous the
Microformats community's copyright and patent policy is - we could
arrange that. However, it is going to cost us a sizeable chunk of change
and we wanted to make sure that the community was listening before we
went out and arranged to have that happen.

-- manu

-- 
Manu Sporny
President/CEO, Digital Bazaar, Inc.
http://blog.digitalbazaar.com/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Fwd: [uf-discuss] Legal implications of using Microformats

[Manu Sporny]

Brian Suda wrote:
> --- if you can give-us any other information, who exactly the company
> is, etc and any other information from the legal team we can attempt
> to work around these problems or debunk the FUD.

Our company is Digital Bazaar, Inc. we provide digital content delivery
services (buying and selling music, TV, film and books online) and want
to use several Microformats in development for Bitmunk as well as
integration into Firefox, Songbird, and Democracy Media Player (we're
currently talking with each team about Microformats).

Bitmunk website:
http://www.bitmunk.com/news/

DB corporate website:
http://www.digitalbazaar.com/

For those of you that don't know where this discussion started - it was
started by Guy Fraser on microformats-new:

http://microformats.org/discuss/mail/microformats-new/2007-April/000241.html

The concern is that there is no standard copyright or patent statement
or policy that applies to the entire Microformats website. Specifically
the examples, formats, brainstorming, proposal, draft and specification
pages have a mix of copyright statements (some not at all). This can
cause problems if an individual authors a Microformat without releasing
copyright or patent claims.

Microformats can stick around in the "draft" process for a long time.
Often they have a statement of "intent" to release it under a certain
copyright/royalty-free licensing model. "Intent to provide under no
restrictions" is very different from "provide under no restrictions".

This could affect anybody implementing Microformats like so:

1. Author pulls together examples, formats, brainstorming, proposal and
draft of a Microformat with "intent" to release royalty-free.
2. Author applies for patent without notifying Microformats community.
3. Invented Microformat gets very popular over the next 2 years.
4. Author decides not to follow through with "intent" and instead
decides to sue for patent infringement. OR Author decides not to
relinquish copyright and becomes a nuisance to the community.

While this will probably not happen, a simple change to the Microformats
wiki can ENSURE that it doesn't happen.

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss