Re: [uf-discuss] issue rejection governance? (Was: rel-tag title as tag value)

[Scott Reynen]

On Feb 26, 2007, at 3:39 PM, James Craig wrote:


Mike Kaply wrote:


I want a solution that involves the web page, NOT the server.


I agree, but my response here is not about rel-tag. It uses rel-tag  
as an example in a larger issue regarding issue rejection.


In the month or so I've been on the discussion list, the "rel-tag  
title" issue has been raised many times, indicating a valid need  
for a less-than-ideal alternative. Many of the stake-holders seem  
to have tagspace-enabled sites (Technorati, Flickr, etc.) and,  
while that is the ideal situation, they also seem defiant in their  
willingness to admit creating a tagspace is problematic for many  
users. I tracked down what I believe to be the documentation of the  
first time this issue was rejected.


Quoted from:  http://microformats.org/wiki?title=rel-tag- 
issues&diff=4885&oldid=4881


"Issue 3: It's not reasonable to restrict the host's REST  
implementation according to this spec's rather limited idea of a  
'good' tag URL. The idea of tags as query parameters is rejected  
without justification, for example. Query parameters are a  
perfectly legitimate means of denoting state.' REJECTED, IGNORES  
ESTABLISHED PRACTICE. Flickr and del.icio.us and other tagging  
sites established the defacto standard of having the tag term be  
denoted by the last segment in the URL and thus defined what makes  
a 'good' tag URL. rel-tag has codified this good practice."


I was not on the list at the time, and therefore cannot verify that  
this issue was not discussed openly, but I also cannot find on the  
wiki the due process of issue rejection. Format rejection is  
defined, but issue rejection seems arbitrary. The closest thing I  
can find is "some issues are REJECTED for a number of obvious  
reasons and others contain longer discussions" on the Microformat  
Issues page. I am not implying the uf group step to the  
deliberation level of ISO or the W3C, but some issues should not be  
noted as REJECTED by an individual, at least not without fair  
consideration and voting. If this process exists, or if there is a  
process for rejection APPEAL, it needs to be documented. If it does  
not exist, it needs to be defined.


For example, the previously noted rejection statement seems  
opinionated to me. If for no other reason, the frequency of this  
request demands that it receive more consideration and deliberation.


Naturally we all have opinions, but I think we also share a common  
agreement to follow the microformats process, so if you want to  
pursue an issue either pre- or post-rejection, the process is still  
the best way to do this.  In this case, the rejection includes  
examples of existing tag spaces which follow the established standard  
URL format.  If someone wants to suggest that this standard doesn't  
reflect a clear (80/20) majority of real-world publishing, collecting  
counter-examples (sites that use tags with some other URL format)  
would do a lot to support that argument, and also provide a good  
basis for determining a solution if this is ever considered a  
legitimate issue.  Make your case with real-world examples, and I  
think you'll find rejections come less readily.


But rejections will still come without a lot of justification.  More  
generally, I think you might be missing a fundamental principle of  
microformats: they don't demand reasons for rejection as other  
processes often do.  Much the opposite, microformats demand reasons  
for consideration.  In the interest of stripping microformats down to  
the simplest semantic building blocks (largely the basis of  
widespread adoption success), rejection is the default response to  
any additions.  The process description even starts by discouraging  
more microformats:


http://microformats.org/wiki/process

I think everyone will agree that more documentation would be good,  
but I'd encourage you to better document *why* before asking others  
to better document *why not*.  Again, bringing this back to the rel- 
tag example, anyone who thinks the de facto standard of tag space  
URLs is not reflected in the current rel-tag spec should document  
real-world examples to test that hypothesis.


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

[uf-discuss] Governance proposal (WAS: issue rejection governance)

[Dr. Ernie Prabhakar]

Hi all,

On Feb 26, 2007, at 1:39 PM, James Craig wrote:
I am not implying the uf group step to the deliberation level of  
ISO or the W3C, but some issues should not be noted as REJECTED by  
an individual, at least not without fair consideration and voting.  
If this process exists, or if there is a process for rejection  
APPEAL, it needs to be documented. If it does not exist, it needs  
to be defined.


I agree. This issue has come up several times before, but never seems  
to have gotten traction.  So (as part of my Lenten penance :-) I've  
finally decided to take the bull by the horns and put together a  
proposal for addressing the various governance-related questions that  
have been raised:


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

This may not be a perfect solution, but I really feel we need to do  
*something*.  If nothing else, hopefully this wiki page will help  
capture our current "best thinking", as well as the pros and cons of  
various concrete proposals.


I've also started capturing the "known" governance facts at:

http://microformats.org/wiki/governance

Hopefully someone can add links to any extant policies that we  
already have.


Best,
-- Ernie P.

P.S.  Apologies if this isn't the optimal format, but I haven't heard  
anyone suggest a more constructive approach, and this seems most in  
keeping with how we resolve other issues.






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

[uf-discuss] issue rejection governance? (Was: rel-tag title as tag value)

[James Craig]

Mike Kaply wrote:


I want a solution that involves the web page, NOT the server.


I agree, but my response here is not about rel-tag. It uses rel-tag  
as an example in a larger issue regarding issue rejection.


In the month or so I've been on the discussion list, the "rel-tag  
title" issue has been raised many times, indicating a valid need for  
a less-than-ideal alternative. Many of the stake-holders seem to have  
tagspace-enabled sites (Technorati, Flickr, etc.) and, while that is  
the ideal situation, they also seem defiant in their willingness to  
admit creating a tagspace is problematic for many users. I tracked  
down what I believe to be the documentation of the first time this  
issue was rejected.


Quoted from:  http://microformats.org/wiki?title=rel-tag- 
issues&diff=4885&oldid=4881


"Issue 3: It's not reasonable to restrict the host's REST  
implementation according to this spec's rather limited idea of a  
'good' tag URL. The idea of tags as query parameters is rejected  
without justification, for example. Query parameters are a perfectly  
legitimate means of denoting state.' REJECTED, IGNORES ESTABLISHED  
PRACTICE. Flickr and del.icio.us and other tagging sites established  
the defacto standard of having the tag term be denoted by the last  
segment in the URL and thus defined what makes a 'good' tag URL. rel- 
tag has codified this good practice."


I was not on the list at the time, and therefore cannot verify that  
this issue was not discussed openly, but I also cannot find on the  
wiki the due process of issue rejection. Format rejection is defined,  
but issue rejection seems arbitrary. The closest thing I can find is  
"some issues are REJECTED for a number of obvious reasons and others  
contain longer discussions" on the Microformat Issues page. I am not  
implying the uf group step to the deliberation level of ISO or the  
W3C, but some issues should not be noted as REJECTED by an  
individual, at least not without fair consideration and voting. If  
this process exists, or if there is a process for rejection APPEAL,  
it needs to be documented. If it does not exist, it needs to be defined.


For example, the previously noted rejection statement seems  
opinionated to me. If for no other reason, the frequency of this  
request demands that it receive more consideration and deliberation.


Thanks for your consideration,
James Craig

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

Re: [uf-discuss] country-code may be missing from hCard/adr spec

[Mark Jaroski]

Michael MD wrote:
> >UK is the abbreviated form of United Kingdom.  As such, it should be  in 
> >the content of the tag, or else using the abbr element is  unnecessary. 
> >However, I have no clue as to whether the class country- name is 
> >appropriate for country codes, which seems to be the issue.   I was just 
> >commenting on the general html.
> 
> 
> It looks like what is really needed is a standard way to represent standard 
> country codes - so that machines can look up related information for the 
> country without the hit and miss problems of freeform text names for 
> places. (but keeping it simple for parsers or authors)

I've decided that for my purposes the best thing is to spell out the
country name and let the user's client sort out how to do (or not do)
abbreviation.  Otherwise we might just have formatted address labels with
no structure inside.

-mark

-- 
--
=
-- mark at geekhive dot net --
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] rel-tag title as tag value (Was: Should microformat features (like rel-tag) have explicit scope?)

[Scott Reynen]

On Feb 26, 2007, at 12:13 PM, Angus McIntyre wrote:


On Mon, February 26, 2007 11:53 am, Mike Kaply wrote:

... please don't say "use an external tagspace" The tag might be
an internal only product or a codename, so the tagspace belongs
inside the company.


This actually relates to an issue I've been dealing with.

I have a bunch of places where I want to use rel-tag, but I don't  
want to

send users sailing off to Technorati or wherever. The spec says:

   The destination of a rel="tag" hyperlink is required to be a
   tag space (a place that collates or defines tags) ...

The general behavior that I want is to make the tag a link to a search
results page that lists similarly-tagged items. You can see this  
at, for

example:

http://sexworkersproject.org/publications/archives/factsheets/2005

This is an index page for a set of documents and the tags for the
documents (and by extension, the page) are shown in a gray box at  
the end
of the page; clicking on any tag takes you to a page listing all  
documents

containing that tag. (This may look a little weird on IE6; I'm still
dealing with some of the usual IE CSS rendering issues).

My question is whether the search results page can be said to  
'collate'

the tags in the sense that the spec intends.

Opinions?


I think that looks pretty much the same as any other tag space, a  
collection of content giving a tag additional context.  If you're  
asking because it's a relatively small tag space, I don't think  
that's really relevant.  A tag space that gives context to only one  
tag could communicate as much as the broadest tag space, e.g.  
Wikipedia.  There is good reason to prefer shared tag spaces, for the  
same reason we prefer shared HTML semantics in microformats: it eases  
communication.  But that's only true if the shared tag spaces  
communicate what you want to communicate.  This tag:


http://www.sexworkersproject.org/publications/tag/trafficking

seems to mean something much more specific than this tag:

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

and Wikipedia doesn't appear to have any tag to capture that more  
specific meaning.  If you aren't able to find a tag space that  
communicates the meaning you want, it makes sense for you to  
establish your own tag space.  Please consider adding your tag space  
to the wiki, so others who want to capture the same meaning could use  
it:


http://microformats.org/wiki/rel-tag-spaces

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

Re: [uf-discuss] Introduction; music microformat

[Ian McKellar]

Hi,

I've been lurking on this list for a while and I've recently joined Songbird.

Beyond support for expressing the kind of metadata encoded in ID3 in
HTML around links I'd like to see some more conventions around
defining what parts of the content are semantically related to
particular MP3 links. One starting point might be to look to the model
of expressing lists of MP3s with associated metadata (simple ID3
metadata and richer social or commentary metadata) in the hAtom
framework using the concept of enclosures.

I could imagine I would want to associate hReview, hCard (for either
the artist perhaps), hCal (if it's a live recording) and who knows
what else in the future. Even if a crawler can just work out which
chunk of the page to extract words associated with the music file from
I think that's a huge win.

Ian

On 2/26/07, Marian Steinbach <[EMAIL PROTECTED]> wrote:

Hello everybody!

I'd like to briefly introduce myself to the list.

I just joined the list because I am interested in the development of
(a) "music" microformats.

I am running an experimental spider that tries to gather information
about downloadable music from web pages. The problem here is of course
that metadata in ID3 tags is pretty "expensive" to access, both for
the spider and the publisher.

For those of you who haven't heard about the Songbird project (which I
am NOT part of) yet, they have the exact same problem. When a Songbird
user acesses web pages, Songbird scans the page for media links. It
then tries to acces ID3 information within the audio files in order to
extract title, artist, album, genre and duration.

Songbird developers are thus interested in supporting a Microformat
for music/audio/media links. You can read a (very short) discussion
here: http://www.songbirdnest.com/node/1356

According to my research, the music/media-info seems to be stalled
right now. However, I see a huge demand for some format that allows
for very, very simple description of music references.

A whole lot of problems around this have already been adressed within
this group and elsewhere. I'd be happy to learn from you guys about
what's missing.


Cheers,

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





--
Ian McKellar 
ianloic on [flickr | aim | yahoo | skype]
[EMAIL PROTECTED] on [email | jabber | msn]
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] rel-tag title as tag value (Was: Should microformat features (like rel-tag) have explicit scope?)

[Angus McIntyre]

On Mon, February 26, 2007 11:53 am, Mike Kaply wrote:
> ... please don't say "use an external tagspace" The tag might be
> an internal only product or a codename, so the tagspace belongs
> inside the company.

This actually relates to an issue I've been dealing with.

I have a bunch of places where I want to use rel-tag, but I don't want to
send users sailing off to Technorati or wherever. The spec says:

   The destination of a rel="tag" hyperlink is required to be a
   tag space (a place that collates or defines tags) ...

The general behavior that I want is to make the tag a link to a search
results page that lists similarly-tagged items. You can see this at, for
example:

http://sexworkersproject.org/publications/archives/factsheets/2005

This is an index page for a set of documents and the tags for the
documents (and by extension, the page) are shown in a gray box at the end
of the page; clicking on any tag takes you to a page listing all documents
containing that tag. (This may look a little weird on IE6; I'm still
dealing with some of the usual IE CSS rendering issues).

My question is whether the search results page can be said to 'collate'
the tags in the sense that the spec intends.

Opinions?

Angus

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

Re: [uf-discuss] rel-tag title as tag value

[Charles Iliya Krempeaux]

Hello Mike,

On 2/26/07, Mike Kaply <[EMAIL PROTECTED]> wrote:

On 2/26/07, Derrick Lyndon Pallas <[EMAIL PROTECTED]> wrote:
> Obviously, you're the only one that can evaluate your situation; if you
> want to make your application work with rel-tag, you need a conforming
> tag-space. The easiest thing to do would be to set up a redirect that
> takes URLs of the form
>  and maps them to
> existing URLs of the form
> . Then link to the
> former when using rel-tag. This should be very simple to set up in most
> web servers and will help you transition to using the new, nicely named
> tagspace. ~D

So in order to support the rel-tag microformat I have to do server
redirects? Is anyone seeing the problem here?

The answer is, while on apache servers, using mod_rewrite or redirects
is fairly easy, there are app server configurations where redirects
are not as simple as this.

So redirects are not a solution.

I want a solution that involves the web page, NOT the server.


You could create a directory for each tag.

For example...

 http://dogear.example.com/html/tag/collaboration/
 http://dogear.example.com/html/tag/programming/
 http://dogear.example.com/html/tag/linguistics/


See ya

--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] rel-tag title as tag value

[Mike Kaply]

On 2/26/07, Derrick Lyndon Pallas <[EMAIL PROTECTED]> wrote:

Obviously, you're the only one that can evaluate your situation; if you
want to make your application work with rel-tag, you need a conforming
tag-space. The easiest thing to do would be to set up a redirect that
takes URLs of the form
 and maps them to
existing URLs of the form
. Then link to the
former when using rel-tag. This should be very simple to set up in most
web servers and will help you transition to using the new, nicely named
tagspace. ~D


So in order to support the rel-tag microformat I have to do server
redirects? Is anyone seeing the problem here?

The answer is, while on apache servers, using mod_rewrite or redirects
is fairly easy, there are app server configurations where redirects
are not as simple as this.

So redirects are not a solution.

I want a solution that involves the web page, NOT the server.

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

Re: [uf-discuss] rel-tag title as tag value

[Derrick Lyndon Pallas]

Mike Kaply wrote:

The URLs look like this:

http://dogear.example.com/html?tag=collaboration

How do you tag this using rel tag?

If one of the fundamental principles of microformats is the ability to
add microformats to existing web pages, how does it work with existing
tagspaces that don't conform?

Suggestions?


Obviously, you're the only one that can evaluate your situation; if you 
want to make your application work with rel-tag, you need a conforming 
tag-space. The easiest thing to do would be to set up a redirect that 
takes URLs of the form 
 and maps them to 
existing URLs of the form 
. Then link to the 
former when using rel-tag. This should be very simple to set up in most 
web servers and will help you transition to using the new, nicely named 
tagspace. ~D



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

Re: [uf-discuss] rel-tag title as tag value (Was: Should microformat features (like rel-tag) have explicit scope?)

[Mike Kaply]

Let me post a concrete example in this arena, and maybe someone can
come up with some suggestions.

Let's say your company has an internal version of delicious.

The URLs look like this:

http://dogear.example.com/html?tag=collaboration

How do you tag this using rel tag?

If one of the fundamental principles of microformats is the ability to
add microformats to existing web pages, how does it work with existing
tagspaces that don't conform?

And please don't say "harass the developer of the application." That's
being done. The fact remains that the website is already out, and
that's not an easy thing to do.

And also, please don't say "use an external tagspace" The tag might be
an internal only product or a codename, so the tagspace belongs inside
the company.

Suggestions?

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

Re: [uf-discuss] Introduction; music microformat

[Frances Berriman]

On 26/02/07, Marian Steinbach <[EMAIL PROTECTED]> wrote:

Hello everybody!


Hi Marian! Welcome to the -discuss.


I just joined the list because I am interested in the development of
(a) "music" microformats.


Can I take this opportunity, before this thread gets a bit meaty, to
redirect this discussion to the microformats-new list, which is
specifically for the exploration and discussion of new microformats:

http://microformats.org/wiki/mailing-lists#microformats-new

--
Frances Berriman
http://fberriman.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Introduction; music microformat

[Thom Shannon]

There has been some work on this, http://microformats.org/wiki/media-info

Marian Steinbach wrote:

Hello everybody!

I'd like to briefly introduce myself to the list.

I just joined the list because I am interested in the development of
(a) "music" microformats.

I am running an experimental spider that tries to gather information
about downloadable music from web pages. The problem here is of course
that metadata in ID3 tags is pretty "expensive" to access, both for
the spider and the publisher.

For those of you who haven't heard about the Songbird project (which I
am NOT part of) yet, they have the exact same problem. When a Songbird
user acesses web pages, Songbird scans the page for media links. It
then tries to acces ID3 information within the audio files in order to
extract title, artist, album, genre and duration.

Songbird developers are thus interested in supporting a Microformat
for music/audio/media links. You can read a (very short) discussion
here: http://www.songbirdnest.com/node/1356

According to my research, the music/media-info seems to be stalled
right now. However, I see a huge demand for some format that allows
for very, very simple description of music references.

A whole lot of problems around this have already been adressed within
this group and elsewhere. I'd be happy to learn from you guys about
what's missing.


Cheers,

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


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

Re: [uf-discuss] cite/embed a microformat tag from another url

[Lorenzo De Tomasi]

Thank you :-)
I know AHAH, I have understood how to embed a full html doc, but I
don't know the way I can use it to embed only the content of one or
more tags... :-(

On 2/26/07, Jonathan C Williams <[EMAIL PROTECTED]> wrote:

On Feb 25, 2007, at 6:54 PM, Lorenzo De Tomasi wrote:

> Hi,
> is it possible to "cite"/embed/import a microformat tag from another
> website, using javascript/php + dom or another open web technology?
> For example I would like to create a web page that gets updated hcards
> of different organizations directly from  their websites...

Saw this on the list before.

http://www.xfront.com/microformats/AHAH.html

--
Jonathan Williams
Web Programmer
NYU Steinhardt
+1 212 998 5308 (office)  +1 401 499 4532 (mobile)
[EMAIL PROTECTED]


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




--
Lorenzo De Tomasi
Designer della comunicazione
http://www.ipernico.it
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] cite/embed a microformat tag from another url

[Jonathan C Williams]

On Feb 25, 2007, at 6:54 PM, Lorenzo De Tomasi wrote:


Hi,
is it possible to "cite"/embed/import a microformat tag from another
website, using javascript/php + dom or another open web technology?
For example I would like to create a web page that gets updated hcards
of different organizations directly from  their websites...


Saw this on the list before.

http://www.xfront.com/microformats/AHAH.html

--
Jonathan Williams
Web Programmer
NYU Steinhardt
+1 212 998 5308 (office)  +1 401 499 4532 (mobile)
[EMAIL PROTECTED]


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

Re: [uf-discuss] Introduction; music microformat

[Rob O'Rourke]

Marian Steinbach wrote:

Hello everybody!

I'd like to briefly introduce myself to the list.

I just joined the list because I am interested in the development of
(a) "music" microformats.

I am running an experimental spider that tries to gather information
about downloadable music from web pages. The problem here is of course
that metadata in ID3 tags is pretty "expensive" to access, both for
the spider and the publisher.

For those of you who haven't heard about the Songbird project (which I
am NOT part of) yet, they have the exact same problem. When a Songbird
user acesses web pages, Songbird scans the page for media links. It
then tries to acces ID3 information within the audio files in order to
extract title, artist, album, genre and duration.

Songbird developers are thus interested in supporting a Microformat
for music/audio/media links. You can read a (very short) discussion
here: http://www.songbirdnest.com/node/1356

According to my research, the music/media-info seems to be stalled
right now. However, I see a huge demand for some format that allows
for very, very simple description of music references.

A whole lot of problems around this have already been adressed within
this group and elsewhere. I'd be happy to learn from you guys about
what's missing.


Cheers,

Marian Steinbach




Hi Marian,

   I would love to see a music microformat too, I was reading about a 
suggestion here 
http://www.bmannconsulting.com/blog/bmann/a-microformat-for-music a 
while back. I don't know enough about mp3 to help with the microformat 
but I have a user-case scenario. Some instances of mp3 and audio appear 
in a flash player, I'm using Jeroen Wijering's flash player for my 
brother's music blog at the moment. It uses an XSPF playlist to get its 
data for urls and to create download links from within the flash. The 
player has a decent javascript interface aswell that I'm currently using 
for accessibility and an auto-resume cookie. If I could use some PHP 
like Magpie RSS to parse the playlist (any suggestions?) I could create 
an XHTML interface to control the mp3 player as opposed to the flash 
interface allowing me to markup playlist items however I wanted, ideally 
as a microformat.


   My suggestion then is to perhaps look at the XSPF (www.xspf.org) 
open format as a basis for the microformat and then extend it with the 
specific mp3 metadata.
If there's to be a microformat for mp3s in particular it would be useful 
to have one for playlists that would encompass the mp3s aswell.


   Can anyone point me to a good entry-level reference or resource 
regarding the metadata associated with mp3s so I can start creating a 
test case 'in the wild'?


   Cheers,
   Rob

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

Re: [uf-discuss] Introduction; music microformat

[Digital Spaghetti]

Hi Marian,

I am interested in this as well, from a content provider point-of-view.  
I am the main developer for a music management company, and I'd like a 
way to mark up our websites (both corporate and the band's) with their 
discography's and tag it using some sort of music microformat.


From my point of view, I'd like to include obvious things such as 
Artist, Album title, track titles, track length, etc as well as other 
non-obvious stuff such as publisher, ISRC codes, territory releases 
(i.e. UK, Japan, US, Canada, etc).  I could see this being useful if 
other music publishers took up the use of this microformat, so anyone 
parsing the data can rely on it being accurate if from a trusted source.


One idea might be rather than looking at ID3 is to try find out how a 
large service (such as iTunes) stores their metadata, and seeing if that 
can be directly applied to semantic markup.


Regards,
Tane

Marian Steinbach wrote:

Hello everybody!

I'd like to briefly introduce myself to the list.

I just joined the list because I am interested in the development of
(a) "music" microformats.

I am running an experimental spider that tries to gather information
about downloadable music from web pages. The problem here is of course
that metadata in ID3 tags is pretty "expensive" to access, both for
the spider and the publisher.

For those of you who haven't heard about the Songbird project (which I
am NOT part of) yet, they have the exact same problem. When a Songbird
user acesses web pages, Songbird scans the page for media links. It
then tries to acces ID3 information within the audio files in order to
extract title, artist, album, genre and duration.

Songbird developers are thus interested in supporting a Microformat
for music/audio/media links. You can read a (very short) discussion
here: http://www.songbirdnest.com/node/1356

According to my research, the music/media-info seems to be stalled
right now. However, I see a huge demand for some format that allows
for very, very simple description of music references.

A whole lot of problems around this have already been adressed within
this group and elsewhere. I'd be happy to learn from you guys about
what's missing.


Cheers,

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



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

Re: [uf-discuss] hCard SOURCE

[Scott Reynen]

On Feb 24, 2007, at 5:43 PM, Joe Andrieu wrote:


Brian Suda wrote:

--- this has managed to span several threads and lots of
messages. I have completely lost track of what people are
TRYING to do, what this actually accomplishes? There is a
pretty intereting application that already does an excellent
job of identity consolidation using the tools we have today.

http://webdd.backnetwork.com/

This is an excellent example for anyone lucky enough to have
been at a conference and played with it. There is some
discussion and slides of how it works[1,2]


Brian, from what I could get from the links provided, webdd is  
using rel=me and XFN, rather than SOURCE. One potential hurdle with
that is the rel applies to full pages only, and can't point to  
individual hCards.


Yeah, even if we could get around the full-page semantics of rel,  
rel="me" only indicates identity, which is only half of what I'm  
looking for.  I agree with Ryan that we should stick with existing  
vCard properties for this, specifically UID.  But even if we used  
rel="me" for that, we'd still have the problem of figuring out which  
hCards should be preferred (by applications that want to give  
preferential treatment to certain hCards) among a set of hCards all  
describing the same person.  I think SOURCE is useful for  
communicating this, and was intended for exactly that purpose.  I'm  
not suggesting changing it at all, only including some examples of  
how to use it in the hCard spec.


The main thing I would like to be able to do is simply provide a  
"brief" hCard that links back to a "full" hCard so that when I show
up where only my name is appropriate, a consuming application (or  
individual) can dereference to the full hCard to get my complete

contact information.


Me too.

-- ok, i think i see you point in that each hCard uses SOURCE 
to say where they got the information from, but each time you

add something to the chain, the SOURCE is the previous link.
'A' gets the data from 'B' (so A uses B's URL as the SOURCE)
'B' got the data from 'C' (so B uses C's URL as the SOURCE).

Are people publishing in this way already? We want to model
user-behavior that already exists.


Yes.  For a single-link chain, look at my example on http:// 
projectvrm.org/Blogs; others have also stated that they do this  
sort of
thing.  Following a chain to its "conclusion" would be one way to  
discover the "most authoritative", but I'd be happy with just one

dereference for now.


It seems to me that whether one or a chain is followed should be up  
to a consuming application, and makes no difference for publishers,  
who can only point the hCards we're publishing to better hCards  
(regardless of how far the chain continues from there).


For a multi-link chain not hCard encoded, see http:// 
microformats.org/wiki/irc-people


Or any blog with comments, which generally point to other blogs,  
which generally point to author profiles.  I think names linking to  
better contact information for a person is one of the most common  
publishing behaviors on the web.  Here's a thousand examples of the  
behavior to get us started:


http://kitchen.technorati.com/contact/search/brian

That class of link is what I want to model, and I think "source" is a  
good name for the class.  (I don't really have any problem with  
rel="via" either, as I think the semantic of "via" is applicable to  
the entire document, as well as the individual abbreviated hCard.)


Currently, this information is invisible to the semantic web.  I  
think hCard with authoritative sources would make it easy to make

it visible.


Right.


--- If we are citing where we got the data from, and each
link my previous example is citing (SOURCEing) where it got
the data from, then the X2V implementation does just this.
When it extracts a vCard from an hCard it uses the URL of the
current page as the SOURCE, even if that hCard used SOURCE
and pointed at a different URL. I'm not (and i don't think
you are) advocating following that chain to the end and using
that hCard. We don't do this with the include-pattern for
vairous reasons.


Actually, I am advocating that, specifically for this use case.


I'm finding "advocating" unclear here.  In RFC-speak [1], I'm saying  
MAY, not SHOULD nor MUST.  Personally, I'd prefer consuming  
applications that see my hCard on someone else's blog to replace it  
with the SOURCEd hCard on my site.  But it's no problem if they  
don't, as I can always use other applications that do.



The semantic I would like to see encoded is that when a "source"
points to an hCard with the same UID, the source hCard is more  
authoritative.


I'd rather not get into defining "authoritative."  For my purposes, a  
source is more authoritative.  But if you want to define  
authoritativeness by the length of the hCard, or the publication  
date, or whatever makes the most sense for your application, that's  
an implementation decision, not defined by the meaning of SO

[uf-discuss] Introduction; music microformat

[Marian Steinbach]

Hello everybody!

I'd like to briefly introduce myself to the list.

I just joined the list because I am interested in the development of
(a) "music" microformats.

I am running an experimental spider that tries to gather information
about downloadable music from web pages. The problem here is of course
that metadata in ID3 tags is pretty "expensive" to access, both for
the spider and the publisher.

For those of you who haven't heard about the Songbird project (which I
am NOT part of) yet, they have the exact same problem. When a Songbird
user acesses web pages, Songbird scans the page for media links. It
then tries to acces ID3 information within the audio files in order to
extract title, artist, album, genre and duration.

Songbird developers are thus interested in supporting a Microformat
for music/audio/media links. You can read a (very short) discussion
here: http://www.songbirdnest.com/node/1356

According to my research, the music/media-info seems to be stalled
right now. However, I see a huge demand for some format that allows
for very, very simple description of music references.

A whole lot of problems around this have already been adressed within
this group and elsewhere. I'd be happy to learn from you guys about
what's missing.


Cheers,

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