Re: [uf-discuss] hCard: url and tel

[Paul Wilkins]

On Jan 9, 2008 8:30 PM, Andy Mabbett <[EMAIL PROTECTED]> wrote:
> Please don't do so on my account. I find such hiatuses (whether
> voluntary or imposed) pointless; far better for the time to be spent
> making constructive contributions to our work here.

I suspect that he realised he had gone too far and has implied a
self-imposed cooling off period for himself to gain perspective on the
situation.

This is something that many of us can learn from, so good job that man, I say.

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik 
<[EMAIL PROTECTED]> writes



Thus, apologies, comment retracted.


Thank you.

Based on this feedback I will refrain from posting on microformats 
mailing lists and making wiki edits (other than admin duties of 
blocking/reverting spammers) for 24 hours.


Please don't do so on my account. I find such hiatuses (whether 
voluntary or imposed) pointless; far better for the time to be spent 
making constructive contributions to our work here.


[I will respond to your other post later]

--
Andy Mabbett

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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/8/08 6:47 AM, "Christopher St John" <[EMAIL PROTECTED]> wrote:

> On Jan 7, 2008 8:14 PM, Tantek Çelik <[EMAIL PROTECTED]> wrote:
>> 
>> The distinction of properties, values, types, schema etc. are well
>> documented computer science terms.
>> 
> 
> Actually, in knowledge representation terms they're
> usually not. To get around the "what's meta" problem
> people generally just pick a level that seems reasonable
> to the problem at hand and go ahead knowing that other
> choices might have been equally valid. (Computer geeks
> can think Java Reflection or the Lisp MOP. When is a
> type actually data? Just don't go there :-) )
> 
> In HTML for example, the "sematic level" of the various
> tags varies quite a bit:  is very generic, 
> very specific, so denying the question isn't helpful to
> those trying to write a new format (or understand the
> logic behind existing formats)
> 
> I generally agree that the discussion of meta-levels can
> be unproductive, but there are choices to be made. A
> better answer to the question about data in class
> attributes might be:
> 
> "Yes, it's data, and there are some fairly deep
> questions about what is appropriate and what is not. We
> tried to cut through the Gordian knot by simply avoiding
> the deep questions. When possible, names are just stolen
> from existing standards (hCard). Otherwise, authors have
> just used intuition to make some reasonable choices.
> There is no hard and fast rule. Different microformats
> have very different sorts of "stuff" in the class
> attribute (just compare xoxo to hReview), the key is to
> make the "stuff" appropriate to the task at hand. If you
> want to author a new microformat, you're going to need
> to make some choices and experience has shown the
> community (and lots of research) will help you with the
> appropriateness of your vocabulary and its 'semantic
> level'. There are also guidelines on the wiki that have
> proven useful in other efforts. Long discussions of the
> what counts as meta often end badly, so don't worry
> about it too much. Instead, concentrate on existing
> practice and trust the community to help with judgement
> calls."


This is a much better answer.

Christopher, perhaps you could consider adding this to the FAQ in answer to
to Katrina's question: "What sort of meta-data is acceptable and what others
aren't?"[1]

http://microformats.org/wiki/faq

[1] 
http://microformats.org/discuss/mail/microformats-discuss/2008-January/01127
8.html


>> One way to
>> learn more about such distinctions is to pick up a book or two on computer
>> science and data structure and learn about them.
>> 
> 
> I don't personally mind a little heat in my technical
> discussions, but this is exactly the sort of remark Andy
> was banned for, and it's unfair to hit a person who
> can't hit back.

Hitting back is still hitting. It doesn't make it right.

Instead, the right thing to do is to simply call it out (as you did).

and...

On 1/8/08 12:08 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

>>  One way to
>> learn more about such distinctions is to pick up a book or two on computer
>> science and data structure and learn about them.
> 
> Yes; they told me that a few years before they awarded me my degree in
> the subject.

My bad for making the assumption that you didn't have a computer science
degree (unfortunately another example of the logical flaw previously noted).

> Your "snarky" comment, against your own policy, also adds little to the
> debate.

Though not intended as snarky, upon re-reading I can see how it could have
been interpreted that way.

Thus, apologies, comment retracted.

Based on this feedback I will refrain from posting on microformats mailing
lists and making wiki edits (other than admin duties of blocking/reverting
spammers) for 24 hours.

Tantek


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

Re: [uf-discuss] hCard: url and tel

[Guillaume Lebleu]

Andy Mabbett wrote:
In message <[EMAIL PROTECTED]>, Guillaume Lebleu 
<[EMAIL PROTECTED]> writes


In that same vein, we could ask: when did you last see a phone 
number  not being a work number when both a person's formatted name 
and  organization name were present?


Today - and nearly every time I look at a contact page about someone 
who does voluntary work.



Can you point to an example that will help me understand your point?




Ok. But I still don't understand why you say that in the case of 
voluntary work, a single tel with an unspecified type cannot be assumed 
to be of type 'work' if an org is present.


The vCard RFC recommends the use of "work" to indicate a telephone 
number associated with a place of work.


The case above seems to qualify: voluntary work... is work and the place 
of work is WMBC and the phone number provided is clearly associated with 
WMBC. So it seems to me legitimate to assume that the tel provided are 
of type 'work' even though it is not explicitly stated in the content.


I still don't get your point. Can you elaborate?

TIA,

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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/8/08 12:08 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, Tantek Çelik
> <[EMAIL PROTECTED]> writes
> 
> 
 properties!=values.  types/schema are not "just as much" data.
>>> 
>>> You seem to be making unsubstantiated assertions and arbitrary
>>> distinctions.
>> 
>> Please stop making the assumption of lack of foundation logical flaw.
> 
> I made no "logical flaw". You posted assertions; and made no attempt to
> substantiate them.

The logical flaw is the *assumption* that your statement made that there was
no (or appeared to be no) foundation/substantiantion for my assertion.  You
can't know that, therefore the assumption is invalid.

Such invalid assumptions do not contribute to debate, and are not helpful.

As I said, rather than assuming a lack of substantiation, simply ask for it,
as the guidelines indicate.


>> http://microformats.org/wiki/mailing-list#Avoid_logical_flaws
>> 
>> > n_or_justification>
> 
> Posting URLs of your own assertions on the wiki as though they were
> evidence contributed little to the debate.

Those are not my assertions, but merely documentation of a logical flaw.

If you dispute that logical flaw, please indicate *why* you think that
logical flaw is itself flawed, perhaps in a nested list item, on the wiki.


>>> Consider:
>>> 
>>>   street- vs. extended- address
>> 
>> sub-properties of adr property
>> 
>>> 
>>>   given- vs. additional- name
>> 
>> sub-properties of n property
>> 
>> 
>>>   work- vs. home- tel
>> 
>> *values* for 'type' sub-property of tel property.
> 
> Arbitrary distinctions.

Not arbitrary, but based on distinctions made in vCard, hence I cited:

>> These distinctions come from RFC 2426 as well as
>> http://microformats.org/wiki/hcard-design-methodology
>> Read both carefully to understand these distinctions better.
> 
> I'm fully aware of both the source and meaning of those terms.

Then I suggest re-reading RFC2426 to better understand the source of the
distinctions, rather than categorizing them as "arbitrary".


>> 
> 
> The examples were not theoretical, but real (though surname changed out
> of courtesy to the person concerned.

Please provide a URL to a public resource on the Web to substantiate the
assertion that they are "real" for the purposes of microformats.


 Hence why microformats focus on real world examples on the web that are
 also *common*.
>>> 
>>> And people *commonly* publish what are clearly and unambiguously (to
>>> humans, but not, without the additional mark-up of a microformat, to
>>> machines) home or work telephone numbers, without saying as much on the
>>> page.
>> 
>> Same thing. needs real world example URL. please document on hcard-issues.
> 
> 

Thank you.  Please document on hcard-issues.


Tantek


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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Guillaume Lebleu 
<[EMAIL PROTECTED]> writes


In that same vein, we could ask: when did you last see a phone 
number  not being a work number when both a person's formatted name 
and  organization name were present?


Today - and nearly every time I look at a contact page about someone 
who does voluntary work.



Can you point to an example that will help me understand your point?




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

Re: [uf-discuss] hCard: url and tel

[Guillaume Lebleu]

Andy Mabbett wrote:





In that same vein, we could ask: when did you last see a phone number 
not being a work number when both a person's formatted name and 
organization name were present?


Today - and nearly every time I look at a contact page about someone 
who does voluntary work.

Andy,

Can you point to an example that will help me understand your point?

TIA,

Guillaume

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

Re: [uf-discuss] hCard: url and tel

[Christopher St John]

On Jan 7, 2008 8:14 PM, Tantek Çelik <[EMAIL PROTECTED]> wrote:
>
> The distinction of properties, values, types, schema etc. are well
> documented computer science terms.
>

Actually, in knowledge representation terms they're
usually not. To get around the "what's meta" problem
people generally just pick a level that seems reasonable
to the problem at hand and go ahead knowing that other
choices might have been equally valid. (Computer geeks
can think Java Reflection or the Lisp MOP. When is a
type actually data? Just don't go there :-) )

In HTML for example, the "sematic level" of the various
tags varies quite a bit:  is very generic, 
very specific, so denying the question isn't helpful to
those trying to write a new format (or understand the
logic behind existing formats)

I generally agree that the discussion of meta-levels can
be unproductive, but there are choices to be made. A
better answer to the question about data in class
attributes might be:

"Yes, it's data, and there are some fairly deep
questions about what is appropriate and what is not. We
tried to cut through the Gordian knot by simply avoiding
the deep questions. When possible, names are just stolen
from existing standards (hCard). Otherwise, authors have
just used intuition to make some reasonable choices.
There is no hard and fast rule. Different microformats
have very different sorts of "stuff" in the class
attribute (just compare xoxo to hReview), the key is to
make the "stuff" appropriate to the task at hand. If you
want to author a new microformat, you're going to need
to make some choices and experience has shown the
community (and lots of research) will help you with the
appropriateness of your vocabulary and its 'semantic
level'. There are also guidelines on the wiki that have
proven useful in other efforts. Long discussions of the
what counts as meta often end badly, so don't worry
about it too much. Instead, concentrate on existing
practice and trust the community to help with judgement
calls."


> One way to
> learn more about such distinctions is to pick up a book or two on computer
> science and data structure and learn about them.
>

I don't personally mind a little heat in my technical
discussions, but this is exactly the sort of remark Andy
was banned for, and it's unfair to hit a person who
can't hit back.


-- 
Christopher St. John
http://artofsystems.blogspot.com

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Guillaume Lebleu 
<[EMAIL PROTECTED]> writes



Andy Mabbett wrote:


When did you last see a listing of, say, Pizza restaurants that labelled
each telephone number as "work"?

When did you last see a listing of, say, Pizza restaurants that included
the managers' home numbers?


In that same vein, we could ask: when did you last see a phone number 
not being a work number when both a person's formatted name and 
organization name were present?


Today - and nearly every time I look at a contact page about someone who 
does voluntary work.


maybe something that would work  would be to have an implied 'work' 
tel type when a fn and an org that  are both present and a tel type is 
not present.


The same thought occurred to me a few hours ago, but I soon realised 
that it would add semantic meaning, incorrectly, to a number of existing 
hCards.


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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Guillaume Lebleu 
<[EMAIL PROTECTED]> writes



Andy Mabbett wrote:


When did you last see a listing of, say, Pizza restaurants that labelled
each telephone number as "work"?

When did you last see a listing of, say, Pizza restaurants that included
the managers' home numbers?


In that same vein, we could ask: when did you last see a phone number 
not being a work number when both a person's formatted name and 
organization name were present?


Today.

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik 
<[EMAIL PROTECTED]> writes




properties!=values.  types/schema are not "just as much" data.


You seem to be making unsubstantiated assertions and arbitrary
distinctions.


Please stop making the assumption of lack of foundation logical flaw.


I made no "logical flaw". You posted assertions; and made no attempt to 
substantiate them.



http://microformats.org/wiki/mailing-list#Avoid_logical_flaws




Posting URLs of your own assertions on the wiki as though they were 
evidence contributed little to the debate.



The distinction of properties, values, types, schema etc. are well
documented computer science terms.

Rather than asserting "unsubstantiated assertions and arbitrary
distinctions", if you don't understand such distinctions, ask.


I understand, thank you. That does not mean that I agree with your use 
of the terms.



 One way to
learn more about such distinctions is to pick up a book or two on computer
science and data structure and learn about them.


Yes; they told me that a few years before they awarded me my degree in 
the subject.


Your "snarky" comment, against your own policy, also adds little to the 
debate.



Consider:

  street- vs. extended- address


sub-properties of adr property



  given- vs. additional- name


sub-properties of n property



  work- vs. home- tel


*values* for 'type' sub-property of tel property.


Arbitrary distinctions.


These distinctions come from RFC 2426 as well as
http://microformats.org/wiki/hcard-design-methodology
Read both carefully to understand these distinctions better.


I'm fully aware of both the source and meaning of those terms.


On 1/7/08 4:59 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:


In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes


Mostly microformats just markup existing data in the page so that
machines can find it and know what type of data it is.





The examples were not theoretical, but real (though surname changed out 
of courtesy to the person concerned.



The "given" and "additional" names are not indicated on the page; not
even by context.



Hence why microformats focus on real world examples on the web that are
also *common*.


And people *commonly* publish what are clearly and unambiguously (to
humans, but not, without the additional mark-up of a microformat, to
machines) home or work telephone numbers, without saying as much on the
page.


Same thing. needs real world example URL. please document on hcard-issues.


OFFS!



--
Andy Mabbett

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

Re: [uf-discuss] hCard: url and tel

[Sarven Capadisli]

I suppose I should have posted this in the mailing list:
http://rbach.priv.at/Microformats/IRC/2007-12-06#T192503

-Sarven


On 1/7/08, Katrina <[EMAIL PROTECTED]> wrote:
> Guillaume Lebleu wrote:
> > Andy Mabbett wrote:
> >>
> >> When did you last see a listing of, say, Pizza restaurants that labelled
> >> each telephone number as "work"?
> >>
> >> When did you last see a listing of, say, Pizza restaurants that included
> >> the managers' home numbers?
> >>
> >>
> > In that same vein, we could ask: when did you last see a phone number
> > not being a work number when both a person's formatted name and
> > organization name were present?
> >
> > So, to avoid the meta discussion and go back to Kat's specific problem
> > (she wants to specify a phone as work but without the content containing
> > "work" or any of its abbreviations), maybe something that would work
> > would be to have an implied 'work' tel type when a fn and an org that
> > are both present and a tel type is not present. I believe we could have
> > an implied 'voice' type in this case as well.
> >
> > Sorry in advance if this idea has already been proposed/discussed.
> >
>
> Awesome and Brilliant.
>
> Thanks Guillaume and Tantek! :))
>
> Kat
>
> ___
> 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: url and tel

[Katrina]

Guillaume Lebleu wrote:

Andy Mabbett wrote:


When did you last see a listing of, say, Pizza restaurants that labelled
each telephone number as "work"?

When did you last see a listing of, say, Pizza restaurants that included
the managers' home numbers?

  
In that same vein, we could ask: when did you last see a phone number 
not being a work number when both a person's formatted name and 
organization name were present?


So, to avoid the meta discussion and go back to Kat's specific problem 
(she wants to specify a phone as work but without the content containing 
"work" or any of its abbreviations), maybe something that would work 
would be to have an implied 'work' tel type when a fn and an org that 
are both present and a tel type is not present. I believe we could have 
an implied 'voice' type in this case as well.


Sorry in advance if this idea has already been proposed/discussed.



Awesome and Brilliant.

Thanks Guillaume and Tantek! :))

Kat

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

Re: [uf-discuss] hCard: url and tel

[Guillaume Lebleu]

Tantek Çelik wrote:

On 1/7/08 5:19 PM, "Guillaume Lebleu" <[EMAIL PROTECTED]> wrote:
  
"voice" in fact is already default value of the type sub-property for tel:


http://microformats.org/wiki/hcard#adr_tel_email_types
  

Thanks for the pointer. Sorry I missed that.

Perhaps you could document your brainstorm for implied 'work' tel type when
fn and org are present (and the same? is this for organization hCards only?)
on the hCard brainstorming page?
  
Just did at 
http://microformats.org/wiki/hcard-brainstorming#Implied_work_tel


Guillaume

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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/7/08 5:19 PM, "Guillaume Lebleu" <[EMAIL PROTECTED]> wrote:

> to avoid the meta discussion and go back to Kat's specific problem
> (she wants to specify a phone as work but without the content containing
> "work" or any of its abbreviations), maybe something that would work
> would be to have an implied 'work' tel type when a fn and an org that
> are both present and a tel type is not present. I believe we could have
> an implied 'voice' type in this case as well.
> 
> Sorry in advance if this idea has already been proposed/discussed.

Hi Guillaume,

"voice" in fact is already default value of the type sub-property for tel:

http://microformats.org/wiki/hcard#adr_tel_email_types

Perhaps you could document your brainstorm for implied 'work' tel type when
fn and org are present (and the same? is this for organization hCards only?)
on the hCard brainstorming page?

 http://microformats.org/wiki/hcard-brainstorming

Citations of URLs of real world examples that demonstrate this use case
would help in consideration.

Thanks,

Tantek

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

Re: [uf-discuss] hCard: url and tel

[Guillaume Lebleu]

Andy Mabbett wrote:


When did you last see a listing of, say, Pizza restaurants that labelled
each telephone number as "work"?

When did you last see a listing of, say, Pizza restaurants that included
the managers' home numbers?

  
In that same vein, we could ask: when did you last see a phone number 
not being a work number when both a person's formatted name and 
organization name were present?


So, to avoid the meta discussion and go back to Kat's specific problem 
(she wants to specify a phone as work but without the content containing 
"work" or any of its abbreviations), maybe something that would work 
would be to have an implied 'work' tel type when a fn and an org that 
are both present and a tel type is not present. I believe we could have 
an implied 'voice' type in this case as well.


Sorry in advance if this idea has already been proposed/discussed.

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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/7/08 4:46 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, Tantek Çelik
> <[EMAIL PROTECTED]> writes
> 
>> On 1/7/08 3:46 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
>> 
 Data in the class attribute is a known anti-pattern.
>>> 
>>> extended-address, street-address, locality, region - all just as much
>>> data in class attributes.
>> 
>> properties!=values.  types/schema are not "just as much" data.
> 
> You seem to be making unsubstantiated assertions and arbitrary
> distinctions.

Please stop making the assumption of lack of foundation logical flaw.

http://microformats.org/wiki/mailing-list#Avoid_logical_flaws



The distinction of properties, values, types, schema etc. are well
documented computer science terms.

Rather than asserting "unsubstantiated assertions and arbitrary
distinctions", if you don't understand such distinctions, ask.  One way to
learn more about such distinctions is to pick up a book or two on computer
science and data structure and learn about them.


> Consider:
> 
>   street- vs. extended- address

sub-properties of adr property

> 
>   given- vs. additional- name

sub-properties of n property


>   work- vs. home- tel

*values* for 'type' sub-property of tel property.

These distinctions come from RFC 2426 as well as
http://microformats.org/wiki/hcard-design-methodology
Read both carefully to understand these distinctions better.


On 1/7/08 4:59 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, Tantek Çelik
> <[EMAIL PROTECTED]> writes
> 
>> Mostly microformats just markup existing data in the page so that
>> machines can find it and know what type of data it is.



> The "given" and "additional" names are not indicated on the page; not
> even by context.

Please provide the real world example URL for "the page" mentioned,
otherwise it is pointless to argue about it.

http://microformats.org/wiki/mailing-list#Use_real_world_examples

And add it to http://microformats.org/wiki/hcard-issues


>> Hence why microformats focus on real world examples on the web that are
>> also *common*.
> 
> And people *commonly* publish what are clearly and unambiguously (to
> humans, but not, without the additional mark-up of a microformat, to
> machines) home or work telephone numbers, without saying as much on the
> page.

Same thing. needs real world example URL. please document on hcard-issues.

Tantek


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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

> Mostly microformats just markup existing data in the page so that
>machines can find it and know what type of data it is.

The name:

Rebecca Jayne Smith

can be marked up - correctly and validly - as either:


Rebecca
Jayne
Smith


or:


Rebecca
Jayne
Smith


The "given" and "additional" names are not indicated on the page; not
even by context.


>Hence why microformats focus on real world examples on the web that are
>also *common*.

And people *commonly* publish what are clearly and unambiguously (to
humans, but not, without the additional mark-up of a microformat, to
machines) home or work telephone numbers, without saying as much on the
page.

When did you last see a listing of, say, Pizza restaurants that labelled
each telephone number as "work"?

When did you last see a listing of, say, Pizza restaurants that included
the managers' home numbers?

-- 
Andy Mabbett

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Katrina <[EMAIL PROTECTED]> 
writes


I just don't seem to understand how the Microformats community decides 
what sort of meta-data is acceptable and what others aren't?


The /community/ doesn't. That's part of the problem.

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>On 1/7/08 3:46 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
>
>>> Data in the class attribute is a known anti-pattern.
>>
>> extended-address, street-address, locality, region - all just as much
>> data in class attributes.
>
>properties!=values.  types/schema are not "just as much" data.

You seem to be making unsubstantiated assertions and arbitrary
distinctions.

Consider:

street- vs. extended- address

work- vs. home- tel

given- vs. additional- name

-- 
Andy Mabbett

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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/7/08 4:01 PM, "Katrina" <[EMAIL PROTECTED]> wrote:

> Tantek Çelik wrote:
>> On 1/7/08 2:42 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
>> 
>>> In message <[EMAIL PROTECTED]>, Tantek Çelik
>>> <[EMAIL PROTECTED]> writes
>>> 
> In any case, how is that different from:
> 
>   7 Jan
> 
> where "2008" is "hidden"?
 title attribute is displayed in tool-tips
>>> in some, but far from all, browsers.
>>> 
>>>   
>>> 
>>>   Values of the title attribute may be rendered by user agents in
>>>   a variety of ways.
>>> 
>>> 
>> 
>> Data in the class attribute is a known anti-pattern.  Not a new issue.
>> 
> 
> I admit I am new to microformats, however, I have always understood
> class attributes to hold a type of data: meta-data. They describe what
> sort of data that particular element holds.

Hi Katrina,

"what sort of data" is what a "type" is, and a type is very distinct from
data itself.

E.g. integer is a type. -1,0,1 are examples of data of that type.


> So if you have a list of
> books, instead of giving it a class attribute of red or blue, it should
> be labeled "books".
> 
> Or more pertinent to the microformats, class="vcard". vcard is meta-data
> saying that this particular element holds a vcard.

It is a very specific kind of meta-data that is a type.

Similar to how the  tag is saying this particular element holds a
paragraph.



> Reading this: 
> http://microformats.org/wiki/anti-patterns#data_in_class_attributes
> 
> I just don't seem to understand how the Microformats community decides
> what sort of meta-data is acceptable and what others aren't?

In general, the term meta-data tends to be more confusing than illuminating,
it means too many different things to different people, and thus we try to
avoid its use in discussions.

microformats simply extend the typing/schema information that HTML itself
has.

Where HTML has a limited vocabulary to markup what data/content is
paragraphs, blockquotes etc.

microformats extends that limited vocabulary, also in a limited way, to
markup what data/content is people, organizations etc.


> I also thought that Microformats were to take human data and translate
> that into machine-readable.

Not quite.  Mostly microformats just markup existing data in the page so
that machines can find it and know what type of data it is.  In some
instances a machine-readable instance of the data is necessary, but those
are both the minority and minimized if at all possible.


> In order to do so, context needs to be
> translated to make it machine readable.
> 
> If you come across a business selling something, as a human, you can
> determine that it is work related, and it doesn't need to be labeled
> 'work'. However, a machine cannot make that distinction and needs to be
> explicitly told. How does the Microformats community then allow people
> normal contextual communication but also specifies the contextual data
> for machines? 

The broader problem of arbitrarily extracting meaning from any human prose
is an Artificial Intelligence problem far beyond that of microformats, and
is deliberately not a goal. Hence why microformats focus on real world
examples on the web that are also *common*.

> Surely the way to do that is through meta-data?

See above.  The term meta-data is too heavily overloaded to be really useful
in a discussion.

Thanks,

Tantek


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

Re: [uf-discuss] hCard: url and tel

[Katrina]

Tantek Çelik wrote:

On 1/7/08 2:42 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:


In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes


In any case, how is that different from:

  7 Jan

where "2008" is "hidden"?

title attribute is displayed in tool-tips

in some, but far from all, browsers.

  

  Values of the title attribute may be rendered by user agents in
  a variety of ways.




Data in the class attribute is a known anti-pattern.  Not a new issue.



I admit I am new to microformats, however, I have always understood 
class attributes to hold a type of data: meta-data. They describe what 
sort of data that particular element holds. So if you have a list of 
books, instead of giving it a class attribute of red or blue, it should 
be labeled "books".


Or more pertinent to the microformats, class="vcard". vcard is meta-data 
saying that this particular element holds a vcard.



Reading this: 
http://microformats.org/wiki/anti-patterns#data_in_class_attributes


I just don't seem to understand how the Microformats community decides 
what sort of meta-data is acceptable and what others aren't?



I also thought that Microformats were to take human data and translate 
that into machine-readable. In order to do so, context needs to be 
translated to make it machine readable.


If you come across a business selling something, as a human, you can 
determine that it is work related, and it doesn't need to be labeled 
'work'. However, a machine cannot make that distinction and needs to be 
explicitly told. How does the Microformats community then allow people 
normal contextual communication but also specifies the contextual data 
for machines?


Surely the way to do that is through meta-data?

Kat




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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/7/08 3:46 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

>> Data in the class attribute is a known anti-pattern.
> 
> extended-address, street-address, locality, region - all just as much
> data in class attributes.

properties!=values.  types/schema are not "just as much" data.

Tantek

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik 
<[EMAIL PROTECTED]> writes



title attribute is displayed in tool-tips


in some, but far from all, browsers.

  

  Values of the title attribute may be rendered by user agents in
  a variety of ways.

Nothing about tool-tips there.


Nonetheless what browsers do implement is a fact.


The "fact" is that that's what *some* browsers do. Many do not.





Perhaps you might wait for resolution of such issues before imposing
your own view on the wiki.


Data in the class attribute is a known anti-pattern.


extended-address, street-address, locality, region - all just as much 
data in class attributes.



Not a new issue.


Perhaps not a new issue.; but also not a black-&-white issue.

--
Andy Mabbett

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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/7/08 2:42 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, Tantek Çelik
> <[EMAIL PROTECTED]> writes
> 
>>> In any case, how is that different from:
>>> 
>>>   7 Jan
>>> 
>>> where "2008" is "hidden"?
>> 
>> title attribute is displayed in tool-tips
> 
> in some, but far from all, browsers.
> 
>   
> 
>   Values of the title attribute may be rendered by user agents in
>   a variety of ways.
> 
> Nothing about tool-tips there.

Nonetheless what browsers do implement is a fact.

>> > _names.3F>
> 
> Perhaps you might wait for resolution of such issues before imposing
> your own view on the wiki.

Data in the class attribute is a known anti-pattern.  Not a new issue.

Tantek


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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>> In any case, how is that different from:
>>
>>   7 Jan
>>
>> where "2008" is "hidden"?
>
>title attribute is displayed in tool-tips

in some, but far from all, browsers.



Values of the title attribute may be rendered by user agents in
a variety of ways.

Nothing about tool-tips there.

>

Perhaps you might wait for resolution of such issues before imposing
your own view on the wiki.

-- 
Andy Mabbett

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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/7/08 11:52 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, ryan
> <[EMAIL PROTECTED]> writes
> 
>> On Jan 6, 2008, at 12:30 PM, Andy Mabbett wrote:
>>> In message <[EMAIL PROTECTED]>, Katrina <[EMAIL PROTECTED]>
>>> writes
>>> 
 I want to specify a work-related telephone number, but I just want to
 label it 'Phone:'. The closest I can find to do this is the abbr,
 however, work is not an abbreviation of 'phone'.
 
 eg. Phone
 
 Q2. Would it be possible to do something like this, instead?
 Phone
>>> 
>>> 
>>> We could - if there is sufficient support - adapt the recently-
>>> proposed
>>> "sub-microformat" pattern, so that:
>>> 
>>> 555
>>> 
>>> becomes parsed as a "work-type" 'phone number.
>> 
>> I don't think we want to do this, because it puts human-readable data
>> ("work") in a spot that's no longer visible.
> 
> Except that, as the OP stated, that it's a work number is clear from the
> context.
> 
> In any case, how is that different from:
> 
>   7 Jan
> 
> where "2008" is "hidden"?

title attribute is displayed in tool-tips and thus is at least semi-visible
and thus human verifiable.

class attribute is not.



Tantek

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, ryan
<[EMAIL PROTECTED]> writes

>On Jan 6, 2008, at 12:30 PM, Andy Mabbett wrote:
>> In message <[EMAIL PROTECTED]>, Katrina <[EMAIL PROTECTED]>
>> writes
>>
>>> I want to specify a work-related telephone number, but I just want to
>>> label it 'Phone:'. The closest I can find to do this is the abbr,
>>> however, work is not an abbreviation of 'phone'.
>>>
>>> eg. Phone
>>>
>>> Q2. Would it be possible to do something like this, instead?
>>> Phone
>>
>>
>> We could - if there is sufficient support - adapt the recently-
>>proposed
>> "sub-microformat" pattern, so that:
>>
>> 555
>>
>> becomes parsed as a "work-type" 'phone number.
>
>I don't think we want to do this, because it puts human-readable data
>("work") in a spot that's no longer visible.

Except that, as the OP stated, that it's a work number is clear from the
context.

In any case, how is that different from:

7 Jan

where "2008" is "hidden"?

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

Re: [uf-discuss] hCard: url and tel

[ryan]

On Jan 6, 2008, at 12:30 PM, Andy Mabbett wrote:

In message <[EMAIL PROTECTED]>, Katrina <[EMAIL PROTECTED]>
writes


I want to specify a work-related telephone number, but I just want to
label it 'Phone:'. The closest I can find to do this is the abbr,
however, work is not an abbreviation of 'phone'.

eg. Phone

Q2. Would it be possible to do something like this, instead?
Phone



We could - if there is sufficient support - adapt the recently- 
proposed

"sub-microformat" pattern, so that:

555

becomes parsed as a "work-type" 'phone number.


I don't think we want to do this, because it puts human-readable data  
("work") in a spot that's no longer visible.


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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, Paul
Wilkins <[EMAIL PROTECTED]> writes

>On Jan 7, 2008 9:54 AM, Andy Mabbett <[EMAIL PROTECTED]> wrote:
>> Nor should you replace "31 Dec 2007" with "2008-01-01", as is currently
>> done in:
>>
>> 31 Dec 2007
>>
>>
>> I can't understand how anyone ever thought that acceptable.
>
>We're going to have to work through this then, because events that end
>at a certain time do not get pushed forward by a day.
>
>With dtend,if the time isn't known it's presumed to be midnight at the
>very start of the day.
>31 Dec 2007
>
>Would it be better if the parser interpreted an ending date with an
>unknown time as the very end of the stated day?
>31 Dec 2007

No, it would be better if a parser accepted, say:


  31 Dec 2007


and wrote "2008-01-01" when outputting an iCalendar file.


That way, we'd be's following the microformats principle of applying
semantics to the data people are already publishing; and making it less
confusing for publishers to do so.

-- 
Andy Mabbett

are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hCard: url and tel

[Karl Dubost]

Le 6 janv. 2008 à 12:34, Katrina a écrit :

Q2. Would it be possible to do something like this, instead?
Phone



Just to make it clear. This is a valid HTML construct. So you can do it.
I do not think it is understood by a microformat extractor (if it  
matters to you)



--
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool






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

Re: [uf-discuss] hCard: url and tel

[Tantek Çelik]

On 1/6/08 9:37 PM, "Paul Wilkins" <[EMAIL PROTECTED]> wrote:

> On Jan 7, 2008 9:54 AM, Andy Mabbett <[EMAIL PROTECTED]> wrote:
>> Nor should you replace "31 Dec 2007" with "2008-01-01", as is currently
>> done in:
>> 
>> 31 Dec 2007
>> 
>> 
>> I can't understand how anyone ever thought that acceptable.
>
>
> We're going to have to work through this then, because events that end
> at a certain time do not get pushed forward by a day.
>
> With dtend,if the time isn't known it's presumed to be midnight at the
> very start of the day.
>   31 Dec 2007

Right.

Note that this is an already documented hCalendar issue:

http://microformats.org/wiki/hcalendar-issues#dtend-date-plus1

Please add any follow-up there rather than in email.

Thanks,

Tantek

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

Re: [uf-discuss] hCard: url and tel

[Paul Wilkins]

On Jan 7, 2008 9:54 AM, Andy Mabbett <[EMAIL PROTECTED]> wrote:
> Nor should you replace "31 Dec 2007" with "2008-01-01", as is currently
> done in:
>
> 31 Dec 2007
>
>
> I can't understand how anyone ever thought that acceptable.

We're going to have to work through this then, because events that end
at a certain time do not get pushed forward by a day.

With dtend,if the time isn't known it's presumed to be midnight at the
very start of the day.
31 Dec 2007

Would it be better if the parser interpreted an ending date with an
unknown time as the very end of the stated day?
31 Dec 2007

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>,
Jim O'Donnell <[EMAIL PROTECTED]> writes

>> @title is only used for abbr for many reasons. I think we have an
>>FAQ for it somewhere, but can't seem to find it right now.
>
>There's one near the bottom of http://microformats.org/wiki/faq but  it
>only mentions dates and times. Types don't work as abbreviations
>because you can't replace the word 'shipments' with 'parcel', or 'US'
>with 'dom'.

Nor should you replace "31 Dec 2007" with "2008-01-01", as is currently
done in:

31 Dec 2007


I can't understand how anyone ever thought that acceptable.


We need a fix, such as (other issues with abbr notwithstanding):


  31 Dec 2007


ASAP, to put the job of making exported ical end-dates exclusive in the
hands of parsers, not publishers.

[the class name could even be "last-day"]

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

Re: [uf-discuss] hCard: url and tel

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Katrina <[EMAIL PROTECTED]>
writes

>I want to specify a work-related telephone number, but I just want to
>label it 'Phone:'. The closest I can find to do this is the abbr,
>however, work is not an abbreviation of 'phone'.
>
>eg. Phone
>
>Q2. Would it be possible to do something like this, instead?
>Phone


We could - if there is sufficient support - adapt the recently-proposed
"sub-microformat" pattern, so that:

555

becomes parsed as a "work-type" 'phone number.


Alternatively (or additionally) we could adopt the previously suggested
"data-title" pattern:

Phone

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

Re: [uf-discuss] hCard: url and tel

[Jim O'Donnell]

On 6 Jan 2008, at 04:20, ryan wrote:


eg. Phone

Q2. Would it be possible to do something like this, instead?
Phone


@title is only used for abbr for many reasons. I think we have an  
FAQ for it somewhere, but can't seem to find it right now.


There's one near the bottom of http://microformats.org/wiki/faq but  
it only mentions dates and times. Types don't work as abbreviations  
because you can't replace the word 'shipments' with 'parcel', or 'US'  
with 'dom'.


Jim

Jim O'Donnell
[EMAIL PROTECTED]
http://eatyourgreens.org.uk
http://flickr.com/photos/eatyourgreens



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

Re: [uf-discuss] hCard: url and tel

[Paul Wilkins]

On Jan 6, 2008 4:34 PM, Katrina <[EMAIL PROTECTED]> wrote:
> I want to specify a work-related telephone number, but I just want to
> label it 'Phone:'. The closest I can find to do this is the abbr,
> however, work is not an abbreviation of 'phone'.
>
> eg. Phone
>
> Q2. Would it be possible to do something like this, instead?
> Phone

Unfortunately not. If you decide to not use the abbr pattern, the
closest that you'll likely be happy with is
work Phone
with the following css
.hidden { display: none; }

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

[Fwd: Re: [uf-discuss] hCard: url and tel]

[Katrina]

Sorry, I pressed reply thinking it would send to the list.

 Original Message 
Subject: Re: [uf-discuss] hCard: url and tel
Date: Sun, 06 Jan 2008 15:10:56 +1030
From: Katrina <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Temperature Technology
To: ryan <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>


ryan wrote:

On Jan 5, 2008, at 7:34 PM, Katrina wrote:

Gday,

I want to specify a work-related telephone number, but I just want to 
label it 'Phone:'. The closest I can find to do this is the abbr, 
however, work is not an abbreviation of 'phone'.


Right, which means you're trying to add information that's not already 
in the document. There's not a way to do this with microformats because 
they're made to markup existing and visible content.


The information is there in the document: it is in the context. The
context means that all information is work related.

Think business cards. They don't have
work: 01234-01234
fax: 01234-01234

written on them. People know it's a work number, due to the context.
Also, what sort of device is 'work'? Is it another fax? Is it a
landline, teletype, modem or mobile, what is it?

Instead, they have
phone: 01234-01234
fax: 01234-01234

However, I think it needs to be more explicit on vCards so that when
imported into address books, the information is placed into the correct
fields.

So my question is how to do that? Take the context and make it explicit
in the hCard/vCard?




eg. Phone

Q2. Would it be possible to do something like this, instead?
Phone


@title is only used for abbr for many reasons. 


If there is no way to specify context in the hCard, doesn't that mean
that whether or not to use microformats is also a choice about semantic
HTML? To choose to use abbr for things that they were never intended
(h, memories of tables ;) )?

Kat

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

Re: [uf-discuss] hCard: url and tel

[ryan]

On Jan 5, 2008, at 7:34 PM, Katrina wrote:

Gday,

Q1. Is there a way to specify if a url is personal or work-related,  
in a similar style to telephone numbers?



I want to specify a work-related telephone number, but I just want  
to label it 'Phone:'. The closest I can find to do this is the  
abbr, however, work is not an abbreviation of 'phone'.


Right, which means you're trying to add information that's not  
already in the document. There's not a way to do this with  
microformats because they're made to markup existing and visible  
content.



eg. Phone

Q2. Would it be possible to do something like this, instead?
Phone


@title is only used for abbr for many reasons. I think we have an FAQ  
for it somewhere, but can't seem to find it right now.


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