W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

Re: SPAM-LOW: Re: VisibleMetadata

From: Mike Schinkel <w3c-lists@mikeschinkel.com>
Date: Thu, 29 Mar 2007 11:29:57 -0400
Message-ID: <460BDB75.2090704@mikeschinkel.com>
To: Maciej Stachowiak <mjs@apple.com>
CC: public-html@w3.org

Maciej Stachowiak wrote:
> On Mar 27, 2007, at 4:54 PM, Mike Schinkel wrote:
>> Murray Maloney wrote:
>>> That's not to say that I don't feel some sympathy for what you are 
>>> trying to say here,
>>> it's just that I can't agree with this design principle as written.
>> I strongly agree with Murray on this. There are many reasons for 
>> visible metadata.  One such reason is an open-source project that I 
>> am working on called T.oolicio.us whose goal is to provide tangible 
>> and visible benefit for invisible metadata.  Without the ability to 
>> add invisible metadata, we will hobble an entire class of web 
>> improvements.
> Do you think that invisible metadata is generally preferable to the 
> visible kind?
Not at all, but that wasn't my point. I'm not arguing against 
visibility, I'm arguing for invisible metadata when visibility is not an 
option. If metadata can be visible then yes, by all means, make it 
visible. But some potential metadata doesn't lend itself to visibility.

Actually your writeup "VisibleMetadata" sounded almost identical to one 
of the non-negotiable principles of Microformat community: "No invisible 
metadata" (except for when the leaders saw a violating use-case they 
liked. ;-) But there are many cases where having invisible metadata is 
better than having no metadata at all that do not contribute to spam.
> Keep in mind these principles are guidelines and few are absolutely 
> inviolate.
But I am saying that it shouldn't be a guideline as stated because then 
extreme justification will be required to "violate" it, and I don't 
think that is appropriate.  It would be better to say that visible 
metadata is preferred when applicable, but not where inappropriate or 
non-applicable.

BTW, many people point to past failings of metadata, i.e. spam, but that 
is only one potential type of metadata and its misuse should not damn 
other potential metadata that is not subject to spam, i.e. what if I 
wanted metadata to say that the case of the URL is not significant, or 
that "/" and  "/Index.HTML" are equivalent?
> Companies that make a business out of organizing information on the 
> web do not generally give weight information that isn't presented to 
> the user.
That's a sweeping statement with no real evidence, unless you mean just 
Google, Yahoo, and Windows Live. If the latter, that omits consideration 
of the many potential who could make use of invisible metadata. One of 
the beauties of the web is how it empowers the little guys, not just the 
big guys.

We basically have a chicken & egg problem with metadata, invisible or 
otherwise; HTML authors don't add it because they get no direct nor 
obvious immediate benefit from it. More importantly the HTML doesn't 
really facilitate adding metadata. If HTML facilitated it more and there 
were projects that used the metadata (like T.oolicio.us) we'd see a lot 
more metadata in use, visible AND invisible, and we'd empower another 
level of value creation on the web.

Look at it another way.  RDF data is invisible metadata.  RSS files are 
(effectively) invisible metadata (what users view RSS files directly?)  
Why can't HTML be used to carry "invisible" information just like that 
embedded within RDF, RSS, and even generic XML? Should we depricate them?

one of my visions is to see broad proliferation of machine-processable 
metadata embedded within HTML across the web. Without allowing, nay 
without encouraging metadata that is not relevant for visual display 
that vision will be severely stunted.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
"It never ceases to amaze how many people will proactively debate away attempts to improve the web..."
Received on Thursday, 29 March 2007 15:30:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 March 2007 15:30:35 GMT