Re: hCard: url and tel

On 1/7/08 4:46 PM, "Andy Mabbett" <andypigsonthewing.org.uk> wrote:

> In message <C3A7FBC6.9A3E3%tantekcs.stanford.edu>, Tantek Çelik
> <tantekcs.stanford.edu> writes
> 
>> On 1/7/08 3:46 PM, "Andy Mabbett"
<andypigsonthewing.org.uk> 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_log
ical_flaws

<http://microformats.org/wiki/logical-
flaws#Assumptions_of_lack_of_foundatio
n_or_justification>

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" <andypigsonthewing.org.uk> wrote:

> In message <C3A801EF.9A3ED%tantekcs.stanford.edu>, Tantek Çelik
> <tantekcs.stanford.edu> writes
> 
>> Mostly microformats just markup existing data in
the page so that
>> machines can find it and know what type of data it
is.

<theoretical example deleted>

> 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_r
eal_world_examples

And add it to http://micr
oformats.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-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message <C3A80E8D.9A3FE%tantekcs.stanford.edu>, Tantek
Çelik 
<tantekcs.stanford.edu> 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_log
ical_flaws
>
><http://microformats.org/wiki/logical-
flaws#Assumptions_of_lack_of_foundatio
>n_or_justification>

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" <andypigsonthewing.org.uk> wrote:
>
>> In message <C3A801EF.9A3ED%tantekcs.stanford.edu>, Tantek Çelik
>> <tantekcs.stanford.edu> writes
>>
>>> Mostly microformats just markup existing data
in the page so that
>>> machines can find it and know what type of data
it is.
>
><theoretical example deleted>

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!

<http://tinyurl.com/2w4r
3v>

-- 
Andy Mabbett

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jan 7, 2008 8:14 PM, Tantek Çelik <tantekcs.stanford.edu> 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: <p> is very generic,
<cite>
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-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss