Re: [uf-discuss] Apple Data Detectors

2008-02-06 Thread Michael MD

But much of these bad things can be aleviated by one of the other
suggestions in this thread: As-you-type validation.  As soon as you
type in Feb for instance, autocomplete style routines kick into
action, helping the author write the date in exactly the right format.
Then as they hit publish it becomes a microformat, proper, with
markup and all.



certainly ... and such things can be good for forms on websites ... but I 
was trying get some useful data out of a whole lot of press releases people 
send me.
(stuff that is normally just ignored because there is nobody with the spare 
time to re-enter it manually!)



--- if only event promoters would mark up those html emails with 
hCalendar!  (and hCard/geo for venues/locations/cities/countries)   :-)


...but of course we are unlikely to see much of that until the email and 
word processing software they are actually using has tools for adding such 
markup to their emails.




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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread Robert O'Rourke

Andy Mabbett wrote:
In message [EMAIL PROTECTED], Robert O'Rourke 
[EMAIL PROTECTED] writes


How about removing the 'contributor' class from the key creator's 
vcard? It would make sense to me to group contributors separately to 
the creator. The vcard attached to the hAudio would denote the 
original creator.


That would still not distinguish between creator as performer (Elvis 
Presley); as composer (Mozart); or as both (Bob Dylan).




Ah yes, so would you say 'performer', 'creator' and 'composer' are roles 
and not different to being a contributor? It would be useful to have a 
more blanket term for instances where one person has multiple roles of 
that kind. 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?

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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread Robert O'Rourke

Martin McEvoy wrote:

Hello Robert
  


Hi Martin, nice meeting you the other day


On Tue, 2008-02-05 at 18:39 +, Robert O'Rourke wrote:
  

For cover tracks you'd have something like:

  span class=contributor vcard
  span class=roleOriginal Artist/span -
  span class=fn orgPrimal Scream/span
  /span 



Here is the best action I have seen using roles, It may be useful to the
discussion.

from http://microformats.org/wiki/hcard-examples-in-wild-reviewed


http://www.iowamilitaryveteransband.com/members/

their roles are the instruments that they play

Roles are *NOT* defined in hAudio as such other than..

The role attribute SHOULD be used to specify the contributor's
responsibility related to the audio recording if hCard is utilized
http://microformats.org/wiki/haudio#Contributor


the context comes from hcard

Information regarding the role of the object
http://microformats.org/wiki/existing-classes

the object in most cases the person.

whats good is, its user defined, we may be able to give sensible hints
to what you put in there but really it's up to the publisher the choice
is yours eg: groupie, or stage hand could be fun!.

original artist, band, group, quartet are valid roles I would
say

so are

vocalist, bassist, drummer, producer, artist for individuals

If we had a hPunchup microformat you could have a role of looser ;)
  


Ha! and a vevent for every punch. Never thought of marking up a boxing 
match until now!



I AM worried that we should be using title instead of role in some
cases...
  


That depends if you look at a piece of music as having jobs associated 
with it. Is a piece of music some work that people were employed to 
create or only a creative endeavour?. It can be either, but as far as 
hAudio is concerned I would say role is most appropriate. Thoughts?



Thanks

Martin McEvoy

  


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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread Martin McEvoy
On Wed, 2008-02-06 at 12:29 +, Robert O'Rourke wrote:
 Martin McEvoy wrote:
  Hello Robert

 
 Hi Martin, nice meeting you the other day

Well met too its surprising the places that you meet people ;)

 
  On Tue, 2008-02-05 at 18:39 +, Robert O'Rourke wrote:

  For cover tracks you'd have something like:
 
span class=contributor vcard
span class=roleOriginal Artist/span -
span class=fn orgPrimal Scream/span
/span 
  
 
  Here is the best action I have seen using roles, It may be useful to the
  discussion.
 
  from http://microformats.org/wiki/hcard-examples-in-wild-reviewed
 
 
  http://www.iowamilitaryveteransband.com/members/
 
  their roles are the instruments that they play
 
  Roles are *NOT* defined in hAudio as such other than..
 
  The role attribute SHOULD be used to specify the contributor's
  responsibility related to the audio recording if hCard is utilized
  http://microformats.org/wiki/haudio#Contributor
 
 
  the context comes from hcard
 
  Information regarding the role of the object
  http://microformats.org/wiki/existing-classes
 
  the object in most cases the person.
 
  whats good is, its user defined, we may be able to give sensible hints
  to what you put in there but really it's up to the publisher the choice
  is yours eg: groupie, or stage hand could be fun!.
 
  original artist, band, group, quartet are valid roles I would
  say
 
  so are
 
  vocalist, bassist, drummer, producer, artist for individuals
 
  If we had a hPunchup microformat you could have a role of looser ;)

 
 Ha! and a vevent for every punch. Never thought of marking up a boxing 
 match until now!

It could be reused in hArgument? ...chuckle

 
  I AM worried that we should be using title instead of role in some
  cases...

 
 That depends if you look at a piece of music as having jobs associated 
 with it. Is a piece of music some work that people were employed to 
 create or only a creative endeavour?. 

In the case of manufactured bands I would say that all involved are 
employed and have Job Titles... as do professional musicians maybe.

 It can be either, but as far as 
 hAudio is concerned I would say role is most appropriate. Thoughts?

I agree Roles are more important than their job titles as the two may
not be related or have any context in the making of a piece of audio.

I think the problem with the above is quite often in audio roles and job
titles are quite often the same..

Manu explained the differences quite nicley to me..

A role is what you do, where a title is what your
official title is at the organization.

Role is hardly ever used in hcard in the real world,and as a result
not much info, I think maybe more information about role can be added
to the hAudio wiki, perhaps even some good recommendations?


Thanks

Martin McEvoy
 
  Thanks
 
  Martin McEvoy
 

 
 Cheers,
 Rob

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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread Robert O'Rourke

Martin McEvoy wrote:

On Wed, 2008-02-06 at 12:29 +, Robert O'Rourke wrote:
  

Martin McEvoy wrote:


I AM worried that we should be using title instead of role in some
cases...
  
  
That depends if you look at a piece of music as having jobs associated 
with it. Is a piece of music some work that people were employed to 
create or only a creative endeavour?. 



In the case of manufactured bands I would say that all involved are 
employed and have Job Titles... as do professional musicians maybe.


  
It can be either, but as far as 
hAudio is concerned I would say role is most appropriate. Thoughts?



I agree Roles are more important than their job titles as the two may
not be related or have any context in the making of a piece of audio.

I think the problem with the above is quite often in audio roles and job
titles are quite often the same..

Manu explained the differences quite nicley to me..

A role is what you do, where a title is what your
official title is at the organization.
  


In that case in relation to hAudio role is defnitely more appropriate. 
Each individual's title is an arbritary thing - say when two people 
who fulfil the same roles at two different organisations have different 
titles. Everyone involved with a recording had a role to play but 
not necessarily an official title.


As a side note, is title only really used if org has been indicated?
And are groups/bands considered to be an organisation?

Solo artists wouldn't have any particular org except maybe the record 
label, in which case their title would be Artist. A musician with no 
record label or contract has no employer and therefore no official 
title so the use of role would be better suited to the majority of 
cases.



Role is hardly ever used in hcard in the real world,and as a result
not much info, I think maybe more information about role can be added
to the hAudio wiki, perhaps even some good recommendations?

  


That would be good to see, there isn't a whole lot of detail about the 
use of role in hcard on the wiki.



Thanks

Martin McEvoy
  



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


[uf-discuss] Re: Possible alternative methods for include

2008-02-06 Thread Toby A Inkster
Ryan King wrote:
 Toby A Inkster wrote:

 It does claim that it's a set of class names, and in mathematical
 parlance sets are unordered by definition, and must not contain
 duplicates, but it's unlikely that the framers of the HTML 4.01 spec
 intended the world set to be interpreted in that way -- far more
 likely they were referring to the layman's definition of the word.
 
 Specs aren't generally written in layman's terms.

What I meant was that the vast majority of the words used in most 
specifications are not explicitly defined, nor are other normative 
references provided giving a definition of them. This is fair enough.
You don't want to read through an enormous glossary at the end of a 
specification defining words such as first, down and the. When
a word is not explicitly defined in the specification itself, or in
a reference, one should assume that the normal everyday meaning of
the word is implied.

I seem to remember reading somewhere that of all the entries in the
Oxford English Dictionary, the word set has the longest, spanning 
several pages. In the context used in the HTML 4.01 spec, I find it
unlikely that they were specifically referring to the mathematical
usage of the word set, unless they were attempting to be
deliberately obscure.

-- 
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 21:25.]

  Looking Ahead to Perl 6
  http://tobyinkster.co.uk/blog/2008/02/05/perl6/

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


[uf-discuss] Re: Possible alternative methods for include

2008-02-06 Thread Toby A Inkster
Paul Wilkins wrote:

 If the ordering of class names were supposed to to have some special
 significance, there would be further information about such a specific
 order. In this case a lack of evidence points to no importance in the
 order of the class names.

If the ordering of paragraphs were supposed to have some special 
significance, there would be further information about such a specific 
order. In this case a lack of evidence points to no importance in the 
order of paragraphs.

Thus the following HTML documents may be rendered identically by a 
conforming browser, right?

titleDocument one/title
pone/p
ptwo/p

titleDocument two/title
ptwo/p
pone/p

The order of the paragraphs doesn't have a special significance, yet the 
paragraphs do have an inherent order. Similarly, the order of class names 
within a class attribute don't have a special significance attached to 
them by the HTML spec, but they do still have an inherent order.

-- 
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 21:47.]

  Looking Ahead to Perl 6
  http://tobyinkster.co.uk/blog/2008/02/05/perl6/

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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread 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

2008-02-06 Thread Andy Mabbett
In message [EMAIL PROTECTED], Martin McEvoy
[EMAIL PROTECTED] writes

Role is hardly ever used in hcard in the real world

I use it. In fact:

http://www.westmidlandbirdclub.com/bardsey/

might include the first ever hCard with a role of Lighthouse keeper!

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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread Andy Mabbett
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.



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...

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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread Andy Mabbett
In message [EMAIL PROTECTED], Robert O'Rourke
[EMAIL PROTECTED] writes

And are groups/bands considered to be an organisation?

Yes:

foo class=fn orgPink Floyd/foo

not least because the alternative:

foo class=fnPink Floyd/foo

would be optimised (sic) to have a given name of Pink and a family
name of Floyd.

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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread Andy Mabbett
In message [EMAIL PROTECTED], Robert O'Rourke
[EMAIL PROTECTED] writes

 would you say 'performer', 'creator' and 'composer' are roles and not
different to being a contributor?

They are all contributors, but they are sub-sets of the set of
contributors (and hence are more granular).

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

Why would it?

How is:

foo class=contributorBob Dylan/foo

more useful than:

foo class=composer performerBob Dylan/foo

The only time I can see the former class name being more useful is where
the finer granularity is unknown or unavailable.

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


Re: [uf-discuss] Re: Possible alternative methods for include

2008-02-06 Thread Paul Wilkins
On Feb 7, 2008 4:36 AM, Toby A Inkster [EMAIL PROTECTED] wrote:
 The order of the paragraphs doesn't have a special significance, yet the
 paragraphs do have an inherent order. Similarly, the order of class names
 within a class attribute don't have a special significance attached to
 them by the HTML spec, but they do still have an inherent order.

There is an inherent order, but that order can not be relied upon to
convey any useful information.

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


Re: [uf-discuss] haudio contributor

2008-02-06 Thread 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

2008-02-06 Thread Guillaume Lebleu

Andy Mabbett wrote:

In message [EMAIL PROTECTED], Robert O'Rourke
[EMAIL PROTECTED] writes

  

And are groups/bands considered to be an organisation?



Yes:

foo class=fn orgPink Floyd/foo

not least because the alternative:

foo class=fnPink Floyd/foo

would be optimised (sic) to have a given name of Pink and a family
name of Floyd.

  

I don't disagree that groups/bands should be considered organisations.

That said, I don't think the reason offered here is a strong one. The 
issue described is directly related to FN's (over?)reuse beyond its 
original vCard scope of person names, to cover any name.


[Not only has this led to the fn/title debate, but it seems some 
implementors are confused between following the vCard semantics (FN only 
for person names) or the hCard ones (FN for any name). See. 
http://cinematreasures.org/theater/365/, which uses an empty FN, 
resulting in their vCard not being detected by Operator, only the address]


Guillaume





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


[uf-discuss] Auto Discovery of XFN

2008-02-06 Thread Robert Mark White
 
 I have a homepage that I use as my OpenId URL.  I have the url of my
homepage delegated to a OpenId provider.
In the header of that homepage I have setup some auto discovery links in
html.  I believe this aids in the discovery of my information. I really do
want a portable social network but I hope to bypass the need to scrape my
information off of a social web site by providing a link as to where the
information I want to provide is already.  
For example,
 
For purely humorous and historical purposes I have the link below.
meta name=ICBM content=39.518869, -104.757254 / 
The link below I use for auto discovery of my foaf file.
link rel=media type=application/rdf+xml title=FOAF
href=http://example.com/foaf.xml; / 
I know this link works as the Semantic Radar add on in Foxfire finds foaf
files all over the net for me.
The link below I use for auto discovery of my avatar/pavatar.
link rel=pavatar type=image/jpg
href=http://example.com/images/771518_1aa9fe4be6_s.jpg;
link rel=avatar type=image/jpg
href=http://example.com/images/771518_1aa9fe4be6_s.jpg;
 
The link below is the link I use for my vCard/hCard.
link rel=media type=text/directory title=vCard
href=http://example.com/vcard.html; /
 
I am only guessing but I am pretty sure that the link about is correct one.
 
I also have a page on my website with my xfn links but I am unable to figure
out the correct information for the auto discovery of it.
 
link rel=media type=?/xfn title=XFN
href=http://example.com/xfn.html; /
 
Can someone please enlighten me as to the correct values for this type link
above?

Sincerely yours,
 
mark
 

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