[uf-discuss] Re: [microformats-discuss] FYI: two posting about the Semantic Web, the "SynWeb", scraping and microformats

[Tantek Ç elik]

On 10/25/05 4:26 AM, "David Janes -- BlogMatrix" <davidjanes at blogmatrix.com>
wrote:

> Danny Ayers wrote:
>> On 10/25/05, Ian Hickson <ian at hixie.ch> wrote:
>>> Humans don't use URIs as keys.
>> 
>> Except when they use the Web.
> 
> +1 :-)

Even then, they don't use *exclusively* use URIs as keys.

They don't even *mostly* use URIs as keys.

I would say they *rarely* use URIs as keys on the Web.

And as Ian would probably point out, humans use the search box in a browser
and type in a term far more often than they type in a URL into the URL box.


> I think that there has to be more to this microformats than simply
> displaying structured data on a webpage for use in and only by itself,

Aggregation.
 

> without the context and usefulness of the entire Internet around it.

Yes, the context is one of the key reasons microformats make more sense than
a bunch of standalone meta-data file silos.


> The 
> web was always about linking

You might say linking documents to documents is what distinguished the web
from earlier efforts, like gopher.

But linking is only one aspect of the web (even if it is the most
distinguishing aspect).


> and the web2.0 [1] theoretically is about
> sharing and remixing.

Yes.


> They key to doing this being able to name objects
> on the Internet

One key to doing so.  Not necessarily the only.

Simply being able to recognize useful chunks of data and doing things with
them is also sufficient to be useful.  Unique IDs (call them URIs if you
wish) for every object are certainly not a requirement for utility, though
they can come in handy in many situations/applications.


> and of course that's URIs (or as Tantek would point out,
> URLs in practice).

Yes.


> We're early in the application phase of microformats (no really, we are)

Yes.


> and so the implications of this are not entirely obvious, but they
> will be. For example, the Microformats Weblog [2] is filled with
> multiple _copies_ of hCards, and fairly half-assed ones at that [3]. But
> why copy? What happened to DRY [4]?

That's a traditional structure-centric viewpoint of what you're seeing at
the microformats.org weblog.

Which came first?  The hCard structure or the name and URL content?

Answer: the name and URL content.

The hCard (and all microformats for that matter) are intended to markup
*existing* content, and content publishing practices.

The right thing to do is to view this from a content-centric viewpoint.

That's the microformats perspective.


> As we become more comfortable of thinking about microformat data as
> being namable objects on the locations,

Here is the irony: what you described as a desirable perspective, that
is"namable objects" with "locations" are *exactly* what the so-called
"half-assed" hCards are, e.g.:

name: Ryan King
location: http://theryanking.com/


> we can -- equally or more
> powerfully to anything we're doing now -- start remixing and pointing
> around and avoid the copying.

We're already there.  Hence why the hCards in use there are as minimal as
they are.


> We can say "my train is 227 at leaves at
> 8:45 AM" [5] or "here's my vcard" [6].

Yes.

Thanks,

Tantek


(references quoted for completeness)

> [1] http://bubble20.blogspot.com/2005/10/bubble-2_11.html
> [2] http://microformats.org/
> [3] *ahem*
> 
> BEGIN:vCard
> FN:Ryan King
> N:King;Ryan;;;
> URL:http://theryanking.com/
> END:vCard
> 
> [4] http://c2.com/cgi-bin/wiki?DontRepeatYourself
> [5] http://caltrain.com/timetable_effective_10_10_05.html#T227A0845 --
> for example
> [6] http://theryanking.com/blog/contact/#vcard -- for example, though
> Ryan doesn't 'id' the microformat. Here's the card:
> 
> BEGIN:vCard
> N:King;Ryan;;;
> FN:Ryan
> TEL;TYPE=CELL:415 260 1398
> EMAIL;TYPE=INTERNET:ryan at theryanking.com
> END:vCard