Ryan's banana fixation

element, e.g.,

Novak

A third web designer embeds a family name in an XML element, e.g., Smith A fourth web designer embeds a family name in an XML element, e.g., Johnson A fifth web designer embeds a family name in an RSS element, e.g., Parker Each of these web designers are expressing the family name information in a way that is resolutely specific and local, i.e., in a way that is appropriate for his/her needs. However, the information is not globally and collectively useful: without a-priori knowledge a web tool cannot ascertain that the information within the elements represents a person's family name. That's where Microformats come into the picture. Add the hCard "family-name" subproperty to each local expression:

Costello

Novak

Smith Johnson Parker Now the information is resolutely specific and local; simultaneously, it is globally and collectively useful. Comments? /Roger From ara.pehlivanian at gmail.com Thu Mar 8 07:04:26 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Thu Mar 8 07:04:31 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: References: Message-ID: <923a87360703080704j5f9140b4g2c6702ced7f34d4b@mail.gmail.com> On 3/8/07, Costello, Roger L. wrote: > Hi Folks, > > Through intense study of Microformats I have come to enlightenment > regarding information design: > > Two Fundamental Principles of Information Design > > 1. Design information to be resolutely specific and local. > > 2. Design information to be globally and collectively useful. > > Example: consider a web designer that embeds a family name in an HTML >

element, e.g., > >

Costello

> > A second web designer embeds a family name in an HTML

element, > e.g., > >

Novak

> > A third web designer embeds a family name in an XML > element, e.g., > > Smith > > A fourth web designer embeds a family name in an XML element, > e.g., > > Johnson > > A fifth web designer embeds a family name in an RSS > element, e.g., > > Parker > > Each of these web designers are expressing the family name information > in a way that is resolutely specific and local, i.e., in a way that is > appropriate for his/her needs. > > However, the information is not globally and collectively useful: > without a-priori knowledge a web tool cannot ascertain that the > information within the elements represents a person's family name. > > That's where Microformats come into the picture. Add the hCard > "family-name" subproperty to each local expression: > >

Costello

> >

Novak

> > Smith > > Johnson > > Parker > > Now the information is resolutely specific and local; simultaneously, > it is globally and collectively useful. > > Comments? > > /Roger > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > Roger, Very clearly articulated. Kudos. I think that the only thing that might be missing there (and maybe I'm just stating the obvious) is the need to express which convention you're applying when using the class value "family-name", i.e. Microformats. That way there won't be any confusion in situations when for example, a product manufacturer releases a list of their products "by family" and marks up their content with the class "family-name", which isn't intended as a Microformat and could be confused by a consuming agent. Perhaps a namespace/schema is required to round off your example. What say you? A. From scott at randomchaos.com Thu Mar 8 08:13:21 2007 From: scott at randomchaos.com (Scott Reynen) Date: Thu Mar 8 08:13:27 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: <923a87360703080704j5f9140b4g2c6702ced7f34d4b@mail.gmail.com> References: <923a87360703080704j5f9140b4g2c6702ced7f34d4b@mail.gmail.com> Message-ID: On Mar 8, 2007, at 9:04 AM, Ara Pehlivanian wrote: > Very clearly articulated. Kudos. I think that the only thing that > might be missing there (and maybe I'm just stating the obvious) is the > need to express which convention you're applying when using the class > value "family-name", i.e. Microformats. That way there won't be any > confusion in situations when for example, a product manufacturer > releases a list of their products "by family" and marks up their > content with the class "family-name", which isn't intended as a > Microformat and could be confused by a consuming agent. Perhaps a > namespace/schema is required to round off your example. > > What say you? In the HTML examples, we're currently using (or recommending anyway) profile URIs for such disambiguation [1], as namespaces are "considered harmful" [2]. The XML examples may require namespaces, but that's generally outside the scope of microformats, which are written specifically for use in (X)HTML [3]. If you're interested in such disambiguation, I'd encourage you to get involved in the ongoing thread on the subject, unfortunately titled "Microformat tools bogosity test." [1] http://microformats.org/wiki/profile-uris [2] http://microformats.org/wiki/namespaces-considered-harmful [3] http://microformats.org/about/ Peace, Scott From ara.pehlivanian at gmail.com Thu Mar 8 08:30:01 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Thu Mar 8 08:30:10 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: References: <923a87360703080704j5f9140b4g2c6702ced7f34d4b@mail.gmail.com> Message-ID: <923a87360703080830j4202923ev10cbf940bb1ed509@mail.gmail.com> On 3/8/07, Scott Reynen wrote: > On Mar 8, 2007, at 9:04 AM, Ara Pehlivanian wrote: > > > Very clearly articulated. Kudos. I think that the only thing that > > might be missing there (and maybe I'm just stating the obvious) is the > > need to express which convention you're applying when using the class > > value "family-name", i.e. Microformats. That way there won't be any > > confusion in situations when for example, a product manufacturer > > releases a list of their products "by family" and marks up their > > content with the class "family-name", which isn't intended as a > > Microformat and could be confused by a consuming agent. Perhaps a > > namespace/schema is required to round off your example. > > > > What say you? > > In the HTML examples, we're currently using (or recommending anyway) > profile URIs for such disambiguation [1], as namespaces are > "considered harmful" [2]. The XML examples may require namespaces, > but that's generally outside the scope of microformats, which are > written specifically for use in (X)HTML [3]. If you're interested in > such disambiguation, I'd encourage you to get involved in the ongoing > thread on the subject, unfortunately titled "Microformat tools > bogosity test." > > [1] http://microformats.org/wiki/profile-uris > [2] http://microformats.org/wiki/namespaces-considered-harmful > [3] http://microformats.org/about/ > > Peace, > Scott > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > Scott, Thanks for the info, I have been tracking the "bogosity test" thread. I'll read up on the info you referenced and I'll start contributing. A. From danny.ayers at gmail.com Thu Mar 8 11:08:29 2007 From: danny.ayers at gmail.com (Danny Ayers) Date: Thu Mar 8 11:08:33 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: References: <923a87360703080704j5f9140b4g2c6702ced7f34d4b@mail.gmail.com> Message-ID: <1f2ed5cd0703081108j60dcac60g6f6e1cc144cea4f7@mail.gmail.com> On 08/03/07, Scott Reynen wrote: > On Mar 8, 2007, at 9:04 AM, Ara Pehlivanian wrote: > > > Very clearly articulated. Kudos. I think that the only thing that > > might be missing there (and maybe I'm just stating the obvious) is the > > need to express which convention you're applying when using the class > > value "family-name", i.e. Microformats. That way there won't be any > > confusion in situations when for example, a product manufacturer > > releases a list of their products "by family" and marks up their > > content with the class "family-name", which isn't intended as a > > Microformat and could be confused by a consuming agent. Perhaps a > > namespace/schema is required to round off your example. > > > > What say you? > > In the HTML examples, we're currently using (or recommending anyway) > profile URIs for such disambiguation [1], as namespaces are > "considered harmful" [2]. Hmm, the arguments against namespaces may work in regard to XML/HTML docs on the web, but "considered harmful" seems a broad stroke (they're pretty handy in other contexts, like programming languages, and work a treat in RDF). But the point about reuse of terms is a good one. But anyhow, avoidance of naming clashes is the usual argument for namespaces, in the current context this isn't really an issue, as the names are determined and shared through convention. But there is a specific aspect of disambiguation that's worth bearing in mind around formats - the prevention of name squatting. An analogous issue appears with "Well-known URLs" such as robots.txt, the problem summed up by Tim Berners-Lee (on TAG) as: [[ The architecture of the web is that the space of identifiers on an http web site is owned by the owner of the domain name. The owner, "publisher", is free to allocate identifiers and define how they are served. Any variation from this breaks the web. ]] A format like HTML has parts where the publisher can use their own definitions. But the publisher's freedom is at risk if there are well-known terms already in the space. Rather than breaking the web, it's breaking the format. For example,

Novak

etc. might work fine, but imagine you later discover an established practice amongst biologists:

Microhylidae

. Turns out their existing systems consider your Costellos, Novaks and Smiths as a classification term, alongside Narrow-mouthed frogs. This is still really talking about naming clashes, but changes the emphasis a little. Rather than saying: 'we're ok to create a convention using class="?4m1??-n4m3", no-one will ever use that by accident' It's taking the responsibility locally by saying: 'we're ok to create a convention using class="family-name" because we have mechanisms in place that mean other people aren't prevented from using it for their own purposes' In HTML, profile URIs are such a mechanism, and preempt such problems. An additional benefit is that they use the web to good effect - the URI can be dereferenced and further information obtained. Cheers, Danny. [1] http://microformats.org/wiki/profile-uris [2] http://microformats.org/wiki/namespaces-considered-harmful [3] http://microformats.org/about/ [4] http://www.w3.org/2001/tag/issues.html#siteData-36 -- http://dannyayers.com From lists at iandavis.com Thu Mar 8 11:16:00 2007 From: lists at iandavis.com (Ian Davis) Date: Thu Mar 8 11:16:15 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: References: Message-ID: <45F060F0.1000602@iandavis.com> On 08/03/2007 13:47, Costello, Roger L. wrote: > That's where Microformats come into the picture. Add the hCard > "family-name" subproperty to each local expression: > >

Costello

> >

Novak

> > Smith > > Johnson > > Parker > > Now the information is resolutely specific and local; simultaneously, > it is globally and collectively useful. What are the coordination costs of each author finding and agreeing to use the same class values? Those costs are cheapest when the specifications are centralized (e.g. microformats.org) but doesn't that centralization act as a bottleneck to development? To get this kind of coordination the authors have to wait until the appropriate specification has been agreed. I think there are similarities here with the coordination costs of something like Xanadu (which required cooperation between parties to form links) and the WWW (which doesn't, I can link to Google without them linking to me). It was the elimination of coordination costs that allowed authors to work independently and allowed the exponential growth of the web. Ian From ara.pehlivanian at gmail.com Thu Mar 8 11:43:24 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Thu Mar 8 11:43:28 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: <45F060F0.1000602@iandavis.com> References: <45F060F0.1000602@iandavis.com> Message-ID: <923a87360703081143r79528bf1v3f449dedfb6b1fa2@mail.gmail.com> On 3/8/07, Ian Davis wrote: > On 08/03/2007 13:47, Costello, Roger L. wrote: > > That's where Microformats come into the picture. Add the hCard > > "family-name" subproperty to each local expression: > > > >

Costello

> > > >

Novak

> > > > Smith > > > > Johnson > > > > Parker > > > > Now the information is resolutely specific and local; simultaneously, > > it is globally and collectively useful. > > What are the coordination costs of each author finding and agreeing to > use the same class values? Those costs are cheapest when the > specifications are centralized (e.g. microformats.org) but doesn't that > centralization act as a bottleneck to development? To get this kind of > coordination the authors have to wait until the appropriate > specification has been agreed. > > I think there are similarities here with the coordination costs of > something like Xanadu (which required cooperation between parties to > form links) and the WWW (which doesn't, I can link to Google without > them linking to me). It was the elimination of coordination costs that > allowed authors to work independently and allowed the exponential growth > of the web. > > Ian > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > Ian, I understand what you're saying about letting authors write their markup freely as opposed to bottlnecking the process. The trouble with that however, is the ensuing chaos that emerges when you want to do anything useful with the data being generated by those very same authors. What I think your contrast of microformats' bottleneck with the web's free growth is missing is the notion that there indeed /was/ a "bottleneck" in the development of the web in the form of Tim Berners-Lee. It's just that it was all up front and not distributed throughout its growth. When he invented HTML, he did the same kind of work we're trying to do with microformats, but he did it by himself and presented it to the community as a fait-accompli. I believe that the growth of any data format requires some agreed upon standard for its consumers to use. Otherwise, how can you ensure reliable consumption of the information if you don't have any idea what you're going to get? It's like parsing XML from an unknown source without a schema. If you want the benefit from the fruit of microformats, you need to pay the cost of developing it. Besides, it's like the old adage goes, nothing worth having comes easily. Cheers, A. From lists at iandavis.com Thu Mar 8 12:26:43 2007 From: lists at iandavis.com (Ian Davis) Date: Thu Mar 8 12:26:47 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: <923a87360703081143r79528bf1v3f449dedfb6b1fa2@mail.gmail.com> References: <45F060F0.1000602@iandavis.com> <923a87360703081143r79528bf1v3f449dedfb6b1fa2@mail.gmail.com> Message-ID: <45F07183.40907@iandavis.com> Hi Ara, On 08/03/2007 19:43, Ara Pehlivanian wrote: > What I think your contrast of microformats' bottleneck with the web's > free growth is missing is the notion that there indeed /was/ a > "bottleneck" in the development of the web in the form of Tim > Berners-Lee. It's just that it was all up front and not distributed > throughout its growth. When he invented HTML, he did the same kind of > work we're trying to do with microformats, but he did it by himself > and presented it to the community as a fait-accompli. Maybe I'm misunderstanding but you appear to be saying that creation of each microformat is equivalent to creating HTML, i.e. a set of useful elements people can use for creative expression. Under the microformats process that effort needs to be centralised to prevent name collision, semantic drift and duplication of effort. There's no way to allow parallel development and then work out how to coordinate differences later. This means there's a limit to the scalability of the mf development process. > > I believe that the growth of any data format requires some agreed upon > standard for its consumers to use. Otherwise, how can you ensure > reliable consumption of the information if you don't have any idea > what you're going to get? It's like parsing XML from an unknown source > without a schema. I think the agreements can occur in parallel between interested and motivated parties. But that's not the impression I get of the microformats process. It isn't a microformat until it's blessed by the mf community. Here's a great microformat that's been developed outside the mf community: http://selfdescription.org/ Has anyone here heard of it, evaluated it or have an opinion on it? Its development followed the mf principles with an extensive survey of existing practice and a distillation of that into a set of common and reasonably humanly accessible terms. I provided some mentorship to the author as part of his Masters (of which this formed the thesis) Ian From scott at randomchaos.com Thu Mar 8 13:55:16 2007 From: scott at randomchaos.com (Scott Reynen) Date: Thu Mar 8 13:55:24 2007 Subject: Not all semantic HTML is a microformat (Was: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design) In-Reply-To: <45F07183.40907@iandavis.com> References: <45F060F0.1000602@iandavis.com> <923a87360703081143r79528bf1v3f449dedfb6b1fa2@mail.gmail.com> <45F07183.40907@iandavis.com> Message-ID: On Mar 8, 2007, at 2:26 PM, Ian Davis wrote: > Hi Ara, > > On 08/03/2007 19:43, Ara Pehlivanian wrote: >> What I think your contrast of microformats' bottleneck with the web's >> free growth is missing is the notion that there indeed /was/ a >> "bottleneck" in the development of the web in the form of Tim >> Berners-Lee. It's just that it was all up front and not distributed >> throughout its growth. When he invented HTML, he did the same kind of >> work we're trying to do with microformats, but he did it by himself >> and presented it to the community as a fait-accompli. > > Maybe I'm misunderstanding but you appear to be saying that > creation of each microformat is equivalent to creating HTML, i.e. a > set of useful elements people can use for creative expression. > Under the microformats process that effort needs to be centralised > to prevent name collision, semantic drift and duplication of > effort. There's no way to allow parallel development and then work > out how to coordinate differences later. > > This means there's a limit to the scalability of the mf development > process. Yes, there is. I think that's made pretty clear on the about page: > microformats are not: > ... > - infinitely extensible and open-ended > ... > - a panacea for all taxonomies, ontologies, and other such > abstractions > - defining the whole world, or even just boiling the ocean http://microformats.org/about/ > I think the agreements can occur in parallel between interested and > motivated parties. They can, and they do. But they don't often follow the microformats process. > But that's not the impression I get of the microformats process. That's because such smaller-scale agreements fall outside the microformats process. It should be self-evident that two people can talk to each other and agree on what something means. It baffles me that we would need to explicitly state that. But since it's such a common misunderstanding that we somehow control other people's HTML, it would probably be good to make that clearer where we can. > It isn't a microformat until it's blessed by the mf community. No, it isn't a microformat until it follows the process. The microformats community just happens to be the largest community currently dedicated to following the microformats process. There's nothing preventing anyone else from following it in another community, but that doesn't seem to happen much, I expect because it's easier to just use this community. > Here's a great microformat that's been developed outside the mf > community: > > http://selfdescription.org/ I'd say that's semantic HTML, not a microformat, as it doesn't appear to have followed the microformat process. That doesn't mean it won't be useful, but calling any semantic HTML a "microformat" is like calling all feeds "RSS" or calling all JavaScript "AJAX" (both mistakes I see often). It's not a big deal, but it's confusing to people who don't understand the difference, and if enough people do it without anyone correcting them, the terms will lose meaning in common use. I often find I need to clarify if someone talking about "RSS" is really talking about feeds in general, including Atom. I'd rather not feel the same need to clarify what people mean when they say "microformat." > Has anyone here heard of it, evaluated it or have an opinion on it? > Its development followed the mf principles with an extensive survey > of existing practice and a distillation of that into a set of > common and reasonably humanly accessible terms. That's the semantic HTML aspect of the microformats process, but there's more to it than that. For example, early in the process is this sentence: > We want to involve all interested parties in the discussion. http://microformats.org/wiki/process That doesn't seem to have been followed in selfdescription.org. It looks like the work of only one person. Also, he seems to be repeating some of the semantics already available in HTML (e.g. the idea of nodes as containers). Again, none of this prevents the concept from being useful semantic HTML, but I think it's a mistake to call it a microformat. > I provided some mentorship to the author as part of his Masters (of > which this formed the thesis) You might encourage him to bring his work to a larger community (this or any other). Peace, Scott From lists at iandavis.com Thu Mar 8 16:00:49 2007 From: lists at iandavis.com (Ian Davis) Date: Thu Mar 8 16:00:46 2007 Subject: Not all semantic HTML is a microformat (Was: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design) In-Reply-To: References: <45F060F0.1000602@iandavis.com> <923a87360703081143r79528bf1v3f449dedfb6b1fa2@mail.gmail.com> <45F07183.40907@iandavis.com> Message-ID: <45F0A3B1.3000501@iandavis.com> On 08/03/2007 21:55, Scott Reynen wrote: > On Mar 8, 2007, at 2:26 PM, Ian Davis wrote: >> This means there's a limit to the scalability of the mf development >> process. > > Yes, there is. I think that's made pretty clear on the about page: > >> microformats are not: >> ... >> - infinitely extensible and open-ended >> ... >> - a panacea for all taxonomies, ontologies, and other such abstractions >> - defining the whole world, or even just boiling the ocean > > http://microformats.org/about/ Yes I understand that. I don't think 10 people collaborating to agree on a way of expressing information they care about in an interoperable fashion in HTML is ocean boiling. Even if there are 500 such groups, that's still not ocean boiling. That's decentralisation and empowerment. >> Has anyone here heard of it, evaluated it or have an opinion on it? >> Its development followed the mf principles with an extensive survey of >> existing practice and a distillation of that into a set of common and >> reasonably humanly accessible terms. > > That's the semantic HTML aspect of the microformats process, but there's > more to it than that. For example, early in the process is this sentence: > >> We want to involve all interested parties in the discussion. > > http://microformats.org/wiki/process > > That doesn't seem to have been followed in selfdescription.org. It > looks like the work of only one person. True, one person was responsible for writing the document, but there was wider involvement from the collection description community. Anyone on the microformats list interested in collection description? Maybe there are some librarians or archivists. If there aren't then it appears to be impossible to make progress under the microformats process. > > You might encourage him to bring his work to a larger community (this or > any other). I am and will be. > > Peace, > Scott > Thanks, Ian From bjonkman at sobac.com Thu Mar 8 20:53:17 2007 From: bjonkman at sobac.com (Bob Jonkman) Date: Thu Mar 8 20:54:20 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <015f01c76059$66b82b10$bc08a8c0@nzto22> References: <011201c7604c$e171a190$bc08a8c0@nzto22>, <015f01c76059$66b82b10$bc08a8c0@nzto22> Message-ID: <45F0A1ED.3510.2001717@bjonkman.sobac.com> This is what said about "Re: [uf-discuss] Formatting arbitra" on 7 Mar 2007 at 14:39 > From: James Craig > > In this case, I think what you are looking for is the 'datetime' > attribute on INS and DEL elements. > > 5 March 2007 Nope... > From: Paul Wilkins > > So it's not the date that's the relevant part, it's the software release > instead. Erm, neither. My usage isn't meant to refer to a change in the document in which it appears (ruling out the semantic use of and ), nor is it meant to refer to software releases in particular. Let me try again: Today I bought an old newspaper from 2 July 2006 These are arbitrary dates, NOT related to the publishing date of the document it appears in, not related to any resources such as a software release. I simply want dates occuring within prose to be recognized as machine-readable dates. This is for both for screen readers and disabiguation of dates such as 3/2/2006 or 02-03-06. It's also useful when quoting text with poorly formatted dates, without altering the presentation of the original quote, eg. The Constitution of 4/7/76 Andy Mabbett suggested a class of "dtstamp" which comes closer to what I intend, but the iCalendar property DTSTAMP is specifically meant to indicate when an iCalendar object was created, which is not the case here. Following the design pattern for dates, I think we need a semantic classname such as "datetime" which James Craig pointed out is an attribute for and March 2, 2006 Does such a classname for an arbitrary date/time already exist? -- -- -- -- Bob Jonkman http://sobac.com/sobac/ SOBAC Microcomputer Services Voice: +1-519-669-0388 6 James Street, Elmira ON Canada N3B 1L5 Cel: +1-519-635-9413 Networking -- Office & Business Automation -- Consulting PGP:0xAE33E989 Fingrprnt:9FAF A6AC B567 BC10 8973 7CF0 CB27 0317 From kevinmarks at mac.com Fri Mar 9 01:06:13 2007 From: kevinmarks at mac.com (Kevin Marks) Date: Fri Mar 9 01:06:21 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: <1f2ed5cd0703081108j60dcac60g6f6e1cc144cea4f7@mail.gmail.com> References: <923a87360703080704j5f9140b4g2c6702ced7f34d4b@mail.gmail.com> <1f2ed5cd0703081108j60dcac60g6f6e1cc144cea4f7@mail.gmail.com> Message-ID: <223BE6E3-8154-448F-A128-32D3F61A9AFD@mac.com> On Mar 8, 2007, at 11:08 AM, Danny Ayers wrote: > For example,
Novak
etc. might work fine, > but imagine you later discover an established practice amongst > biologists:
Microhylidae
. Turns out > their existing systems consider your Costellos, Novaks and Smiths as a > classification term, alongside Narrow-mouthed frogs. As their systems are astronomically unlikely to have wrapped their taxa in a vcard class, there is no clash. Can you stop just making stuff up and pretending this is a problem please? > It's taking the responsibility locally by saying: > > 'we're ok to create a convention using class="family-name" because we > have mechanisms in place that mean other people aren't prevented from > using it for their own purposes' Yes, wrapping it in a container class deliberately chosen to be rare. > In HTML, profile URIs are such a mechanism, and preempt such problems. > > An additional benefit is that they use the web to good effect - the > URI can be dereferenced and further information obtained. Profile URIs can be used to do that, or as you illustrated, they can be used to cause problems. From pmw57 at xtra.co.nz Fri Mar 9 01:33:50 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Fri Mar 9 01:33:57 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <45F0A1ED.3510.2001717@bjonkman.sobac.com> References: <011201c7604c$e171a190$bc08a8c0@nzto22>, <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> Message-ID: <45F129FE.8080306@xtra.co.nz> Bob Jonkman wrote: >Erm, neither. My usage isn't meant to refer to a change in the document in which it appears >(ruling out the semantic use of and ), nor is it meant to refer to software >releases in particular. Let me try again: > > Today I bought an old > newspaper from 2 July 2006 > >These are arbitrary dates, NOT related to the publishing date of the document it appears in, >not related to any resources such as a software release. I simply want dates occuring within >prose to be recognized as machine-readable dates. This is for both for screen readers and >disabiguation of dates such as 3/2/2006 or 02-03-06. It's also useful when quoting text with >poorly formatted dates, without altering the presentation of the original quote, eg. > > The Constitution of 4/7/76 > > From what James was saying before, screen readers are going to misbehave with that kind of design pattern. For abbr to be used, the information in the title has to be more meaningful to the human, than the information contained within. >Andy Mabbett suggested a class of "dtstamp" which comes closer to what I intend, but the >iCalendar property DTSTAMP is specifically meant to indicate when an iCalendar object was >created, which is not the case here. > >Following the design pattern for dates, I think we need a semantic classname such as >"datetime" which James Craig pointed out is an attribute for and > > March 2, 2006 > >Does such a classname for an arbitrary date/time already exist? > > Not for an arbitrary one. See http://microformats.org/wiki/naming-principles#dt_properties A difficulty that I see here is that the abbr for March 2, 2006 doesn't disambiguate. It's perfectly clear what's going on in that particular case. With the previous example, you might write the date as 4/7/76 and force the reader to find and use the abbreviation, but as someone who cares enough to create a datetime design pattern, it should be obvious that writing the date as July 4, 1776 solves the problem. Another trouble is that with the arbitrary datetime pattern in use, how can the machine benefit from that information. It's not immediately clear. So I have to ask, if the text can be more easily rewritten to be clearer, and the abbr element isn't going to allow the information to be processed by some program, then are we just creating a microformat here just for the sake of creating one? Steps one and two of the microformat principles http://microformats.org/wiki/microformats#the_microformats_principles are * Solve a specific problem * Start as simple as possible Problem. Date 02-03-06 can be misunderstood. Solution: Write the date as March 2, 2006 or 2nd of March, 2006 -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From pmw57 at xtra.co.nz Fri Mar 9 02:15:07 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Fri Mar 9 02:16:43 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <45F0A1ED.3510.2001717@bjonkman.sobac.com> References: <011201c7604c$e171a190$bc08a8c0@nzto22>, <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> Message-ID: <45F133AB.80205@xtra.co.nz> Bob Jonkman wrote: >I simply want dates occuring within >prose to be recognized as machine-readable dates. > Why do you want them to eb recognised as machine readable dates? What problem will it solve for the machines? >This is for both for screen readers and >disabiguation of dates such as 3/2/2006 or 02-03-06. > As I'm to believe, screen readers will read out both parts of the date information. As such, having the title as 4 July 1776 will mean the screen reader will read "The Constitution of 4 7 76 4 July 1776" >It's also useful when quoting text with >poorly formatted dates, without altering the presentation of the original quote, eg. > > The Constitution of 4/7/76 > > That is the one example in which the abbr element could be usefully used. The abbr element doesn't require a class, because there is no problem that having such a format will currently solve. The microformat principles mention something similar, in that "Lots of corporate inventors working with plenty of experience, over-designing a format for what //might// be needed some day." http://microformats.org/wiki/microformats#the_microformats_principles As the title is currently for screen readers or to disambiguate the date, it should be kept in a human understandable format. The Constitution of 4/7/76 There is some very useful information from the Manual of Style on the formatting of dates and numbers. http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28dates_and_numbers%29 The following is a direct quote of the relevant parts. Incorrect date formats * Do not use numbers to express a month, except in ISO 8601 format. Always express a month as a whole word (e.g. "February" /not/ "2"). Do not use abbreviations like "Feb" unless the available space is extremely limited, such as in a table, infobox, or the like. * Do not use two digits to express a year unless at the end of a range, e.g., "1970?87" (the same for BC). In all other cases, use four digits for years and decades after AD 999 (the same for BC). Using the less formal two-digit form for a decade is acceptable when not ambiguous; for example, when referring to the decade of the 20th century known as "the eighties", use "1980s" or, less often, "the '80s", not just "80s". * Use consistent date formatting throughout an article, unless there is a good reason to vary it. * Do not use ordinal suffixes: o Incorrect: "February 14th" and "14th February" o Correct: "February 14" and "14 February" * Do not use articles: o Incorrect: "the 14th of February" o Correct: "February 14" and "14 February" * Do not put a comma or the word "of" between a month and year: o Incorrect: "December, 1945" and "December of 1945" o Correct: "December 1945" * Do not use an apostrophe to indicate a decade: o Incorrect: 1970's o Correct: 1970s Direct quotations An important exception to these guidelines is that direct quotations?the word-for-word reproduction of a written or oral text?should /not/ be altered to conform to the Wikipedia "Manual of Style". In other words, a paragraph such as this (fictional) quotation from a newspaper report is fine as is: "Tony Blair, responding to critics in his party, said 'The world has totally changed since the 11th of September.' He was echoing earlier sentiments by Lord Ronald McDonald, who said that 'nine-eleven' was the day that the American public woke up to the reality of terrorism." -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From danny.ayers at gmail.com Fri Mar 9 03:10:02 2007 From: danny.ayers at gmail.com (Danny Ayers) Date: Fri Mar 9 03:10:08 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: <223BE6E3-8154-448F-A128-32D3F61A9AFD@mac.com> References: <923a87360703080704j5f9140b4g2c6702ced7f34d4b@mail.gmail.com> <1f2ed5cd0703081108j60dcac60g6f6e1cc144cea4f7@mail.gmail.com> <223BE6E3-8154-448F-A128-32D3F61A9AFD@mac.com> Message-ID: <1f2ed5cd0703090310n3d4d4ef3ice9f15136245e17e@mail.gmail.com> On 09/03/07, Kevin Marks wrote: > > On Mar 8, 2007, at 11:08 AM, Danny Ayers wrote: > > > For example,
Novak
etc. might work fine, > > but imagine you later discover an established practice amongst > > biologists:
Microhylidae
. Turns out > > their existing systems consider your Costellos, Novaks and Smiths as a > > classification term, alongside Narrow-mouthed frogs. > > As their systems are astronomically unlikely to have wrapped their > taxa in a vcard class, there is no clash. > > Can you stop just making stuff up and pretending this is a problem > please? Ok. But I'd be grateful if you'd look at: http://www.pragmaticprogrammer.com/ppbook/extracts/coincidence.html > > It's taking the responsibility locally by saying: > > > > 'we're ok to create a convention using class="family-name" because we > > have mechanisms in place that mean other people aren't prevented from > > using it for their own purposes' > > Yes, wrapping it in a container class deliberately chosen to be rare. > > > In HTML, profile URIs are such a mechanism, and preempt such problems. > > > > An additional benefit is that they use the web to good effect - the > > URI can be dereferenced and further information obtained. > > Profile URIs can be used to do that, or as you illustrated, they can > be used to cause problems. Personally I prefer the approach of exploiting existing facilities in the HTML spec (Meta data profiles) and following known good practices in regards to web architecture over relying on an ad hoc disambiguation mechanism which I don't believe is explicitly specified anywhere. But clearly we disagree, I'll leave it there. Cheers, Danny. -- http://dannyayers.com From lists at iandavis.com Fri Mar 9 03:38:47 2007 From: lists at iandavis.com (Ian Davis) Date: Fri Mar 9 03:38:47 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: <223BE6E3-8154-448F-A128-32D3F61A9AFD@mac.com> References: <923a87360703080704j5f9140b4g2c6702ced7f34d4b@mail.gmail.com> <1f2ed5cd0703081108j60dcac60g6f6e1cc144cea4f7@mail.gmail.com> <223BE6E3-8154-448F-A128-32D3F61A9AFD@mac.com> Message-ID: <45F14747.2030304@iandavis.com> On 09/03/2007 09:06, Kevin Marks wrote: > > On Mar 8, 2007, at 11:08 AM, Danny Ayers wrote: > >> For example,
Novak
etc. might work fine, >> but imagine you later discover an established practice amongst >> biologists:
Microhylidae
. Turns out >> their existing systems consider your Costellos, Novaks and Smiths as a >> classification term, alongside Narrow-mouthed frogs. > > As their systems are astronomically unlikely to have wrapped their taxa > in a vcard class, there is no clash. So class="vcard" namespaces the terms because it encloses it. Sort of like data islands. > > Can you stop just making stuff up and pretending this is a problem please? > I don't think that's the problem, or you're missing the point in your eagerness to dismiss this issue. The consequences of what you're saying is that mf.org has laid claim to the wrapper class names so no-one can ever use them in their markup to mean anything else, across the whole web for all time. >> It's taking the responsibility locally by saying: >> >> 'we're ok to create a convention using class="family-name" because we >> have mechanisms in place that mean other people aren't prevented from >> using it for their own purposes' > > Yes, wrapping it in a container class deliberately chosen to be rare. Why not use something that is known to be unique instead of guessing? Ian From ara.pehlivanian at gmail.com Fri Mar 9 07:10:35 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Fri Mar 9 07:10:39 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <45F0A1ED.3510.2001717@bjonkman.sobac.com> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> Message-ID: <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> On 3/8/07, Bob Jonkman wrote: > These are arbitrary dates, NOT related to the publishing date of the document it appears in, > not related to any resources such as a software release. I simply want dates occuring within > prose to be recognized as machine-readable dates. This is for both for screen readers and > disabiguation of dates such as 3/2/2006 or 02-03-06. It's also useful when quoting text with > poorly formatted dates, without altering the presentation of the original quote, eg. > > The Constitution of 4/7/76 > > Andy Mabbett suggested a class of "dtstamp" which comes closer to what I intend, but the > iCalendar property DTSTAMP is specifically meant to indicate when an iCalendar object was > created, which is not the case here. > > > Following the design pattern for dates, I think we need a semantic classname such as > "datetime" which James Craig pointed out is an attribute for and > > March 2, 2006 > > Does such a classname for an arbitrary date/time already exist? > I've always had trouble with the idea of using to mark up dates because semantically, it isn't expressing an abbreviation of any sort. It's simply a different form of the same date. I also have a hard time with the idea of using and because their semantic meaning is to express content that's been changed[1]. I really think that what's needed, in line with what you're asking, is a class name that's canonized as a microformat along these lines: July 2, 2006 In this case, the title serves to provide the accurate datetime data while the content within the tags can be tailored to the author's preference and country/language while still being machine readable. 1- http://www.w3.org/TR/html4/struct/text.html#h-9.4 Cheers, A. -- Ara Pehlivanian Site: http://arapehlivanian.com/ Email & GTalk: ara.pehlivanian@gmail.com MSN: ara_p@hotmail.com Twitter: http://twitter.com/ara_p/ From scott at randomchaos.com Fri Mar 9 07:58:35 2007 From: scott at randomchaos.com (Scott Reynen) Date: Fri Mar 9 07:58:51 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> Message-ID: On Mar 9, 2007, at 9:10 AM, Ara Pehlivanian wrote: > I've always had trouble with the idea of using to mark up dates > because semantically, it isn't expressing an abbreviation of any sort. I think the confusion here is that we're actually using "abbreviation" more semantically than literally. That is, it's not the character count that's abbreviated; it's the meaning. (I didn't find this in a FAQ anywhere, but it comes up often enough that I think it should be added. I'd be happy to add my own explanation if it makes sense, but I'm sure I've seen others offer better explanations.) > It's simply a different form of the same date. What we're wrapping in is not simply different; it's less meaningful to machines. If it weren't, we'd have no need for . And can publish something like that with no , e.g.: 2007-03-09 But if you want to communicate the full meaning to a machine while communicating less to humans (who can apply external knowledge, e.g. "March" = "03"), is the appropriate way to abbreviate the communication for humans. > I also have a hard time > with the idea of using and because their semantic meaning > is to express content that's been changed[1]. I agree. > I really think that what's needed, in line with what you're asking, is > a class name that's canonized as a microformat along these lines: > > July 2, 2006 I see a couple problems with this markup. The content "July 2, 2006" is not properly classified as "iso" here, as that's not an ISO date. It looks like you're trying to use the class attribute to classify the content of the title attribute, but that doesn't work in s because the contents of the title attribute in s are not assumed to be equivalent to the element contents. Per HTML specs, the title attribute in s has less specific meaning than the title attribute in s. In , like most elements, "This attribute offers advisory information about the element for which it is set." [1]. But in , "The title attribute of these elements may be used to provide the full or expanded form of the expression." [2] So to use to provide the full form, we need to add to HTML's existing semantics, whereas already contains those semantics, as long as we think of it as abbreviated information rather than abbreviated character count. This is all relevant to existing specific-purpose date-time properties, but I think Paul was right to point out that we don't yet have a compelling use case for generic date information, so it's too early to be discussing markup for that. What exactly would we want to do with a generic date apart from any specific context? If it's only to influence how screen readers read the information aloud, we should probably get some screen reader developers involved in the discussion to ensure they adhere to whatever standard we try to establish. But I suspect there are better groups to tackle that problem, e.g. WCAG [3]. [1] http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 [2] http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 [3] http://www.w3.org/TR/WAI-WEBCONTENT/ Peace, Scott From ara.pehlivanian at gmail.com Fri Mar 9 08:35:24 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Fri Mar 9 08:35:52 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> Message-ID: <923a87360703090835j4cf1aa8au9918392a8cb8fdc3@mail.gmail.com> On 3/9/07, Scott Reynen wrote: > On Mar 9, 2007, at 9:10 AM, Ara Pehlivanian wrote: > > I think the confusion here is that we're actually using > "abbreviation" more semantically than literally. That is, it's not > the character count that's abbreviated; it's the meaning. All of the definitions[1] for abbreviation state that it's a shortening of the original. What you're saying is that "shortening" in this application is making it more human friendly. I think that's stretching the intended definition a bit. Considering that the abbreviated form is in fact /translated/ and not /shortened/, from one notation to another (alphanumeric, more chars, human readable --> numeric, potentially less chars, machine readable). However, since we find ourselves in a situation where no tag exists to explicitly wrap date content, we need to find a best fit and if it means stretching the meaning of a tag, so be it. It's the one that comes closest to what we need. > > I really think that what's needed, in line with what you're asking, is > > a class name that's canonized as a microformat along these lines: > > > > July 2, 2006 > > I see a couple problems with this markup. The content "July 2, 2006" > is not properly classified as "iso" here, as that's not an ISO date. Good point. The class applies to the contents of the span, not the title. My bad. > the title attribute in s has less specific meaning than the > title attribute in s. In , like most elements, "This > attribute offers advisory information about the element for which it > is set." [1]. But in , "The title attribute of these elements > may be used to provide the full or expanded form of the > expression." [2] So to use to provide the full form, we need > to add to HTML's existing semantics, whereas already contains > those semantics, as long as we think of it as abbreviated information > rather than abbreviated character count. The added semantics of the tag's title attribute does definitely lend itself better to our purpose. > This is all relevant to existing specific-purpose date-time > properties, but I think Paul was right to point out that we don't yet > have a compelling use case for generic date information, so it's too > early to be discussing markup for that. What exactly would we want > to do with a generic date apart from any specific context? Well, blog posts and articles online come to mind. They're normally dated, yet there's no convention that states that "this is how you should date an article". Especially when you have a list of articles and all of them have dates (RSS's pubDate would be a real world example of this sort of thing). Maybe what we need are specific microformats for specific uses (like the article list example) but all using the same convention. 1-http://dictionary.reference.com/browse/abbreviated Cheers, A -- Ara Pehlivanian Site: http://arapehlivanian.com/ Email & GTalk: ara.pehlivanian@gmail.com MSN: ara_p@hotmail.com Twitter: http://twitter.com/ara_p/ From hsivonen at iki.fi Sat Mar 10 11:46:15 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Sat Mar 10 11:46:21 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator Message-ID: I needed a .bib-based bibliography generator for XHTML, so I wrote one with help from a friend who had developed a .bib parser. The output of my generator can be seen at http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#references I've wrapped the values of .bib fields in elements whose class name is the .bib field name. I did it just in case. I don't have any consumer use case for those class names. It was just super-easy to generate them. My use case (publishing an academic paper with a bibliography) is not mentioned as a use case at http://microformats.org/wiki/citation-brainstorming . More to the point, the wiki has no consumer use case for my publication use case. Does this mean that hCite is not for me at all? If hCite is for me, what's the elevator pitch convincing me to put more effort into my generator? What benefits should I expect if I do? Is hCite mature enough to be implemented yet? Moreover, is it even possible to generate hCite from my source data (http://hsivonen.iki.fi/thesis/dippa.bib) without sacrificing the presentation that I want and without potentially generating bogus markup for personal names? For example, my source data does not encode explicitly the given name, the family name and other stuff that isn't quite neither. As far as I can tell, it is impossible to tell heuristically that the middle token in these two names is semantically different: Gavin Thomas Nicol Henrik Frystyk Nielsen -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From pmw57 at xtra.co.nz Sat Mar 10 13:10:43 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sat Mar 10 13:10:59 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator Message-ID: <45F31ED3.90500@xtra.co.nz> Henri Sivonen wrote: > I needed a .bib-based bibliography generator for XHTML, so I wrote > one with help from a friend who had developed a .bib parser. The > output of my generator can be seen at > http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#references > > I've wrapped the values of .bib fields in elements whose class name > is the .bib field name. I did it just in case. I don't have any > consumer use case for those class names. It was just super-easy to > generate them. > > My use case (publishing an academic paper with a bibliography) is not > mentioned as a use case at > http://microformats.org/wiki/citation-brainstorming . More to the > point, the wiki has no consumer use case for my publication use case. > > Does this mean that hCite is not for me at all? Not at all. You are using the BibTex format, which is covered in the citation formats http://microformats.org/wiki/citation-formats > If hCite is for me, what's the elevator pitch convincing me to put > more effort into my generator? What benefits should I expect if I do? > Is hCite mature enough to be implemented yet? The citation microformat is a work in progress at this stage, so it's not mature enough for programs to extract information from it, yet examples of current use are being asked for at http://microformats.org/wiki/citation-examples so that most popular uses will be catered for. The benefits are that people visitng your content with next generation tools wil be able to easily extract and use the information in more interesting and useful ways. Tantek has a recent presentation about the big picture of microformats at http://tantek.com/presentations/2007/02/microformats/ > Moreover, is it even possible to generate hCite from my source data > (http://hsivonen.iki.fi/thesis/dippa.bib) without sacrificing the > presentation that I want and without potentially generating bogus > markup for personal names? One of the big ideas behind the use of microformats is that it will allow you to markup the content on your page without modifying the presentation of it. > For example, my source data does not encode explicitly the given > name, the family name and other stuff that isn't quite neither. As > far as I can tell, it is impossible to tell heuristically that the > middle token in these two names is semantically different: > Gavin Thomas Nicol > Henrik Frystyk Nielsen Those issues haven't yet been covered for for the citation microformat. It may be possible for for a generator to parse through them and extract the appropriate information though. For example, honorific-prefix and honorific-suffix are a rather short list. Then after those, the given name, family name and additional name could be extracted in that particular order. -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From romakimmy at gmail.com Sun Mar 11 09:48:18 2007 From: romakimmy at gmail.com (Kim Franch) Date: Sun Mar 11 09:48:25 2007 Subject: [uf-discuss] hCard email & type properties Message-ID: Hello, I am working on an AddressBook type module for Drupal using hCard and have run up against a minor quandrum in correctly formatting email (& to a lesser extent url) properties. I've read through hCard information on this mailing list and found a type of answer, but I'd like to pick your collective brains, if I may. The inital problem I encountered with both propeties stemmed from the fact that I hook into another Drupal module for link managment and click-through tracking, the latter using a redirect after logging the click-through. Scanning through the list I found the following possible solutions: http://microformats.org/discuss/mail/microformats-discuss/2006-April/003605.html http://microformats.org/discuss/mail/microformats-discuss/2006-August/005242.html http://microformats.org/discuss/mail/microformats-discuss/2006-September/005643.html http://microformats.org/wiki/hcard#Human_vs._Machine_readable My confusion comes when trying to impliment email types. I used the following markup: Email FooBar Similarly: FooBar Webpage >From what I've read through, I believed this would be correct, while keeping markup to a minimum. However, checking my hcard markup using the Tails & Operator Firefox extensions proved troublesome in the fact that when exporting the cards 'Email FooBar' showed up as the email address instead of random@foo.com. Tails would show the correct email address in the sidebar, but not in the exportation. I realise that potential issues with these extentions are outside the scope of this list; I would appreiciate, though, comment or suggestions on the above markup. Best regards, K.Franch From pmw57 at xtra.co.nz Sun Mar 11 11:23:04 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sun Mar 11 11:23:11 2007 Subject: [uf-discuss] hCard email & type properties Message-ID: <45F45718.1090107@xtra.co.nz> Kim Franch wrote: > My confusion comes when trying to impliment email types. I used the > following markup: > > > > Email FooBar > > The markup appears to be correct, as when your code is added to an hcard with a test name, the tool at http://suda.co.uk/projects/X2V/ pulls out the correct information. The type of internet and preferred aren't necessary, as internet is the default email type, and as there is only one email address listed for them, there is strictly no preferred one to refer to. > From what I've read through, I believed this would be correct, while > keeping markup to a minimum. However, checking my hcard markup using > the Tails & Operator Firefox extensions proved troublesome in the fact > that when exporting the cards 'Email FooBar' showed up as the email > address instead of random@foo.com. Tails would show the correct email > address in the sidebar, but not in the exportation. > > I realise that potential issues with these extentions are outside the > scope of this list; I would appreiciate, though, comment or > suggestions on the above markup. What you may be facing is that some tools aren't as of yet fully complete. As an example, Operator is an alpha release right now, and doesn't appear to support some abbr design patterns. The most up-to-date one typically being http://suda.co.uk/projects/X2V/ -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From ara.pehlivanian at gmail.com Sun Mar 11 17:06:34 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Sun Mar 11 17:06:38 2007 Subject: [uf-discuss] An Inconvenient hCard Message-ID: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> I've got a bit of a problem with an hCard that I need to mark up and I was wondering if anyone could lend me a hand. I realize the syntax requires that a type be specified for telephone numbers ("voice", "fax", etc...) and that's where my problem lies. It's inconvenient to have the word "voice" appear in the markup because that's not how the convention (at least in this neck of the woods) is when writing out contact information. The final display should be: Tel.: (514) 123-4567 Fax: (514) 123-4568 Yet with the required "voice"/"fax" types it ends up like this: Voice Tel.: (514) 123-4567 Fax Fax: (514) 123-4568 or in the French version of the page: Voice T?l.: (514) 123-4567 Fax T?l?c.: (514) 123-4568 I realize that it's simple enough to just hide the types via CSS, but being the strict standards advocate that I am, I don't like entangling the structural layer with the presentational one by making it dependent on it. The idea of superfluous words littering my markup without proper grammatical consideration doesn't sit well with me. I thought of doing something like this: Tel.: (514) 123-4567 (Voice) Fax: (514) 123-4567 (Fax) or in the French: T?l.: (514) 123-4567 (Voice) T?l?c.: (514) 123-4568 (Fax) But it's redundant in English and nonsensical in French. So, dear Microformats community, please lend me a hand and help me unravel this conundrum of mine. Cheers, A. -- Ara Pehlivanian Site: http://arapehlivanian.com/ Email & GTalk: ara.pehlivanian@gmail.com MSN: ara_p@hotmail.com Twitter: http://twitter.com/ara_p/ From pmw57 at xtra.co.nz Sun Mar 11 17:27:19 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sun Mar 11 17:27:22 2007 Subject: [uf-discuss] An Inconvenient hCard References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> Message-ID: <008501c76445$93f97a30$bc08a8c0@nzto22> From: "Ara Pehlivanian" > I've got a bit of a problem with an hCard that I need to mark up and I > was wondering if anyone could lend me a hand. > > I realize the syntax requires that a type be specified for telephone > numbers ("voice", "fax", etc...) and that's where my problem lies. > It's inconvenient to have the word "voice" appear in the markup > because that's not how the convention (at least in this neck of the > woods) is when writing out contact information. The final display > should be: > > Tel.: (514) 123-4567 > Fax: (514) 123-4568 > > Yet with the required "voice"/"fax" types it ends up like this: > > Voice Tel.: (514) 123-4567 > Fax Fax: (514) 123-4568 > So, dear Microformats community, please lend me a hand and help me > unravel this conundrum of mine. Good news, the voice type is the default one, so you don't have to specify the voice type at all, and only specify for the fax (in this case). With that, you can have
Tel: (514) 123-4567

Fax: (514) 123-4568
-- Paul Wilkins From ara.pehlivanian at gmail.com Sun Mar 11 17:37:24 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Sun Mar 11 17:37:28 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <008501c76445$93f97a30$bc08a8c0@nzto22> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> Message-ID: <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> On 3/11/07, Paul Wilkins wrote: > Good news, the voice type is the default one, so you don't have to specify > the voice type at all, and only specify for the fax (in this case). > > With that, you can have >
Tel: (514) 123-4567
>
Fax: (514) > 123-4568
Thanks Paul. That's really helpful. Any ideas about internationalization? How would I handle "fax" in French? I doubt that "T?l?copieur" would be a valid type, since RFC 2426 doesn't seem to be geared toward types in other languages. Cheers, A. From pmw57 at xtra.co.nz Sun Mar 11 17:43:35 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sun Mar 11 17:43:39 2007 Subject: [uf-discuss] An Inconvenient hCard References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> Message-ID: <008a01c76447$d9951430$bc08a8c0@nzto22> From: "Paul Wilkins" > With that, you can have >
Tel: (514) 123-4567
>
Fax: (514) > 123-4568
Correction:
Tel: (514) 123-4567

Fax: (514) 123-4568
The good thing about keeping the tel class in the paragraph is that if the type and value aren't yet understood by a parser, the appropriate content will still make it through. -- Paul Wilkins From pmw57 at xtra.co.nz Sun Mar 11 17:49:32 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sun Mar 11 17:49:41 2007 Subject: [uf-discuss] An Inconvenient hCard References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com><008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> Message-ID: <009701c76448$af3382c0$bc08a8c0@nzto22> From: "Ara Pehlivanian" > On 3/11/07, Paul Wilkins wrote: >> Good news, the voice type is the default one, so you don't have to >> specify >> the voice type at all, and only specify for the fax (in this case). >> >> With that, you can have >>
Tel: (514) 123-4567
>>
Fax: (514) >> 123-4568
> > Thanks Paul. That's really helpful. > > Any ideas about internationalization? How would I handle "fax" in > French? I doubt that "T?l?copieur" would be a valid type, since RFC > 2426 doesn't seem to be geared toward types in other languages. If the word doesn't appear in the expected english (yeah I know, us damned english) then you would have to use the abbr design pattern. With the abbr design pattern, you encode the machine-readable info around the human-readable words.
T?l?c: (514) 123-4568
http://microformats.org/wiki/abbr-design-pattern has more details on the abbre design pattern. -- Paul Wilkins From ara.pehlivanian at gmail.com Sun Mar 11 18:30:17 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Sun Mar 11 18:30:21 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <009701c76448$af3382c0$bc08a8c0@nzto22> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> <009701c76448$af3382c0$bc08a8c0@nzto22> Message-ID: <923a87360703111930t4ea6fb3aif399f36772e5935@mail.gmail.com> On 3/11/07, Paul Wilkins wrote: > From: "Ara Pehlivanian" > > Any ideas about internationalization? How would I handle "fax" in > > French? I doubt that "T?l?copieur" would be a valid type, since RFC > > 2426 doesn't seem to be geared toward types in other languages. > > If the word doesn't appear in the expected english (yeah I know, us damned > english) then you would have to use the abbr design pattern. > > With the abbr design pattern, you encode the machine-readable info around > the human-readable words. >
T?l?c: class="value">(514) 123-4568
> > http://microformats.org/wiki/abbr-design-pattern has more details on the > abbre design pattern. Sweet! Thank you! A. From microformats at kaply.com Sun Mar 11 18:47:17 2007 From: microformats at kaply.com (Mike Kaply) Date: Sun Mar 11 18:47:21 2007 Subject: [uf-discuss] hCard email & type properties In-Reply-To: References: Message-ID: On 3/11/07, Kim Franch wrote: > > > Email FooBar > > This markup is incorrect. title can only be used with an abbr - the title on a span wont work. Why aren't you just using a mailto? > > > FooBar Webpage > This works for me in the the current operator. I don't understand why you are using this pattern though? Why not just have a anchor that points to the web page? Mike Kaply From scott at randomchaos.com Sun Mar 11 19:07:24 2007 From: scott at randomchaos.com (Scott Reynen) Date: Sun Mar 11 19:07:33 2007 Subject: [uf-discuss] hCard email & type properties In-Reply-To: References: Message-ID: <5BAFF5BD-278D-4B9C-B90A-4FCF94BCEF6F@randomchaos.com> On Mar 11, 2007, at 9:47 PM, Mike Kaply wrote: > This markup is incorrect. title can only be used with an abbr - the > title on a span wont work. To clarify, the title attribute only acts as a replacement of content on , but the title attribute on is valid HTML markup for generally describing content. It's just not particularly useful for microformats. Peace, Scott From pmw57 at xtra.co.nz Sun Mar 11 19:21:43 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sun Mar 11 19:21:49 2007 Subject: [uf-discuss] hCard email & type properties References: Message-ID: <00c501c76455$8fa4abc0$bc08a8c0@nzto22> From: "Mike Kaply" > On 3/11/07, Kim Franch wrote: >> >> >> Email FooBar >> >> > > This markup is incorrect. title can only be used with an abbr - the > title on a span wont work. Also, if it's email or uri, it will automatically be internet, and if it's the only one of its type there, then you have no preferance (pref) as it's the only possible choice. > Why aren't you just using a mailto? I suspect because he wants people to be directed to a page where they can get in touch, instead. >> >> FooBar Webpage >> > > This works for me in the the current operator. I don't understand why > you are using this pattern though? Why not just have a anchor that > points to the web page? Perhaps he wants to be a sneaky bastard (tm) and take people to a different version of the website (perhaps a wrapper) while allowing the real website name to be used by people and tools too. -- Paul Wilkins From scott at randomchaos.com Sun Mar 11 20:20:28 2007 From: scott at randomchaos.com (Scott Reynen) Date: Sun Mar 11 20:20:46 2007 Subject: [uf-discuss] hCard email & type properties In-Reply-To: <00c501c76455$8fa4abc0$bc08a8c0@nzto22> References: <00c501c76455$8fa4abc0$bc08a8c0@nzto22> Message-ID: <264B9941-3C0E-4793-AE87-4A3FF0B050EC@randomchaos.com> On Mar 11, 2007, at 10:21 PM, Paul Wilkins wrote: >> Why aren't you just using a mailto? > > I suspect because he wants people to be directed to a page where > they can get in touch, instead. >> Why not just have a anchor that >> points to the web page? > > Perhaps he wants to be a sneaky bastard (tm) and take people to a > different version of the website (perhaps a wrapper) while allowing > the real website name to be used by people and tools too. Wasn't this all explained in the initial question? On Mar 11, 2007, at 12:48 PM, Kim Franch wrote: > The inital problem I encountered with both propeties stemmed from the > fact that I hook into another Drupal module for link managment and > click-through tracking, the latter using a redirect after logging the > click-through. So the goal is to have the href attributes point to click-tracking URLs, but have microformat parsers read the original URLs. Even though this is possible (as others have explained), it seems to violate the microformat principle of designing for humans first, machines second. In this case, machines are getting more useful links than humans. Peace, Scott From pmw57 at xtra.co.nz Sun Mar 11 20:30:25 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sun Mar 11 20:30:33 2007 Subject: [uf-discuss] hCard email & type properties References: <00c501c76455$8fa4abc0$bc08a8c0@nzto22> <264B9941-3C0E-4793-AE87-4A3FF0B050EC@randomchaos.com> Message-ID: <010201c7645f$28ba30b0$bc08a8c0@nzto22> From: "Scott Reynen" >> The inital problem I encountered with both propeties stemmed from the >> fact that I hook into another Drupal module for link managment and >> click-through tracking, the latter using a redirect after logging the >> click-through. > > So the goal is to have the href attributes point to click-tracking URLs, > but have microformat parsers read the original URLs. Even though this is > possible (as others have explained), it seems to violate the microformat > principle of designing for humans first, machines second. In this case, > machines are getting more useful links than humans. Why not then have the normal URL in the markup then use an onmousedown event to update the URL to be what it should with the clickthrough tracking? -- Paul Wilkins From mdagn at spraci.com Mon Mar 12 20:58:22 2007 From: mdagn at spraci.com (Michael MD) Date: Mon Mar 12 01:57:48 2007 Subject: [uf-discuss] hCard email & type properties References: <00c501c76455$8fa4abc0$bc08a8c0@nzto22> Message-ID: <005701c7652c$3ce2c750$116bacca@COMCEN> > >> Why aren't you just using a mailto? > > I suspect because he wants people to be directed to a page where they can > get in touch, instead. > > Perhaps he wants to be a sneaky bastard (tm) and take people to a > different version of the website (perhaps a wrapper) while allowing the > real website name to be used by people and tools too. Perhaps he just wants to take people to a form where people can send him a message rather than put his email address on any page where it could be picked up by spambots. I think this would be quite common. I prefer not to put email addresses on web pages (or I'll try to obfuscate them somehow) for the same reason. What if I want to put a contact form url in there AND (seperately) a website url? If I use class="url" for both how would a parser know which is which? From romakimmy at gmail.com Mon Mar 12 03:35:40 2007 From: romakimmy at gmail.com (Kim Franch) Date: Mon Mar 12 03:35:44 2007 Subject: [uf-discuss] hCard email & type properties In-Reply-To: <005701c7652c$3ce2c750$116bacca@COMCEN> References: <00c501c76455$8fa4abc0$bc08a8c0@nzto22> <005701c7652c$3ce2c750$116bacca@COMCEN> Message-ID: Thank you all for your comments so far. > The type of internet and preferred aren't necessary, as internet is the > default email type, and as there is only one email address listed for > them, there is strictly no preferred one to refer to. > Noted and thank you. Though I started this module for my own ends, I think it might prove useful for the Drupal community and am thus attempting to make it as flexible as possible, including multiple email addresses, url & IM's per entry/hCard. It's still in a very rough stage and you just pointed out a point where I need to smooth the edges out, so to speak. > Why not then have the normal URL in the markup then use an onmousedown event > to update the URL to be what it should with the clickthrough tracking? Because I'd like to stay away from JS for a variety of reasons. A) I'm not that proficient with JS and it drives me rather batty B) I try to KISS and stay away from JS for reasons of accessibility, flexibility, and browsers that have JS disabled/have proprietary DOMs C) Keeping with the sneaky bastard-ess (tm) moniker, for my own personal project I'd need to keep track of clicks as mentioned previously (Think something along the lines of an advertiser's directory or a type of yellow pages for a site). The aim is to eventually try to filter known robot 'clickthroughs' as opposed to actual human clickthroughs. As such, I'm much more comfortable tinkering around with PHP than JS to achieve this end. D) See: A :) > > I suspect because he wants people to be directed to a page where they can > > get in touch, instead. For my own project, yes I have been considering this as well so users can keep track of who/when they have contacted. > So the goal is to have the href attributes point to click-tracking URLs, > but have microformat parsers read the original URLs. Even though this is > possible (as others have explained), it seems to violate the microformat > principle of designing for humans first, machines second. In this case, > machines are getting more useful links than humans. Scott, may I ask you to expound a bit more on this? I suspect my morning cappuccino hasn't kicked in yet, but your last sentence is flying over my head right now. I'm working on this module precisely because I want humans to be able to download/import information from an hCard into their address books/PIMs/PDAs etc. If this info is included in the hCard, why would a redirect link be more useful to machines than humans when the large majority of end users wouldn't know a redirect if it bit them on the bum? best regards, Kim From scott at randomchaos.com Mon Mar 12 07:24:40 2007 From: scott at randomchaos.com (Scott Reynen) Date: Mon Mar 12 07:24:47 2007 Subject: [uf-discuss] hCard email & type properties In-Reply-To: References: <00c501c76455$8fa4abc0$bc08a8c0@nzto22> <005701c7652c$3ce2c750$116bacca@COMCEN> Message-ID: On Mar 12, 2007, at 6:35 AM, Kim Franch wrote: >> So the goal is to have the href attributes point to click- >> tracking URLs, >> but have microformat parsers read the original URLs. Even though >> this is >> possible (as others have explained), it seems to violate the >> microformat >> principle of designing for humans first, machines second. In >> this case, >> machines are getting more useful links than humans. > > Scott, may I ask you to expound a bit more on this? I suspect my > morning cappuccino hasn't kicked in yet, but your last sentence is > flying over my head right now. I'm working on this module precisely > because I want humans to be able to download/import information from > an hCard into their address books/PIMs/PDAs etc. If I right-click on a URL and choose "Add Link to Bookmarks" in my browser, I should ideally get the same link that I would get if I clicked on my microformat parser and imported the hCard. It sounds like I'm getting a different link, that you're presenting different content to different user agents, which is less than ideal. > If this info is > included in the hCard, why would a redirect link be more useful to > machines hCards are intended for machines to parse. Humans can read the content without hCards, but machines can't, so what humans see in their browser is what I mean by "human-readable content," though obviously humans are eventually using the hCard content as well. In your example, the human-readable (browser-rendered) content is less useful than the machine-readable hCard. It's a subtle difference, as both links should eventually end up in the same place, but we should avoid these differences where possible. Peace, Scott From jcraig at apple.com Mon Mar 12 09:43:18 2007 From: jcraig at apple.com (James Craig) Date: Mon Mar 12 09:43:20 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <009701c76448$af3382c0$bc08a8c0@nzto22> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> <009701c76448$af3382c0$bc08a8c0@nzto22> Message-ID: <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> Paul Wilkins wrote: > With the abbr design pattern, you encode the machine-readable info > around the human-readable words. >
T?l?c: class="value">(514) 123-4568
> > http://microformats.org/wiki/abbr-design-pattern has more details > on the abbre design pattern. This is a misuse of abbr at best. See: open issue! 2007-01-26 http://microformats.org/wiki/hcard-issues James From ara.pehlivanian at gmail.com Mon Mar 12 09:54:54 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Mon Mar 12 09:55:08 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> <009701c76448$af3382c0$bc08a8c0@nzto22> <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> Message-ID: <923a87360703121054s4142eff4qa8dd56696a2176a7@mail.gmail.com> On 3/12/07, James Craig wrote: > Paul Wilkins wrote: > > > With the abbr design pattern, you encode the machine-readable info > > around the human-readable words. > >
T?l?c: > class="value">(514) 123-4568
> > > > http://microformats.org/wiki/abbr-design-pattern has more details > > on the abbre design pattern. > > This is a misuse of abbr at best. > > See: open issue! 2007-01-26 > http://microformats.org/wiki/hcard-issues Okay, so what does a guy do in a case like this then? I'd previously raised the point of abbr not really representing an abbreviation in these cases in another thread, but it seems that it's nonetheless accepted as a form of abbreviation. So what do you suggest I do if I can't use abbr? A. -- Ara Pehlivanian Site: http://arapehlivanian.com/ Email & GTalk: ara.pehlivanian@gmail.com MSN: ara_p@hotmail.com Twitter: http://twitter.com/ara_p/ From tjameswhite at yahoo.com Mon Mar 12 11:10:58 2007 From: tjameswhite at yahoo.com (Tim White) Date: Mon Mar 12 11:11:02 2007 Subject: [uf-discuss] An Inconvenient hCard Message-ID: <445373.5808.qm@web30805.mail.mud.yahoo.com> ----- Original Message ---- >From Ara On 3/12/07, James Craig wrote: > Paul Wilkins wrote: > > > With the abbr design pattern, you encode the machine-readable info > > around the human-readable words. > >
T?l?c: > class="value">(514) 123-4568
> This is a misuse of abbr at best. > > See: open issue! 2007-01-26 > http://microformats.org/wiki/hcard-issues >Okay, so what does a guy do in a case like this then? What about something along the lines of:
Telec: (514) 123-4568
Title is a valid HTML attribute and this avoids abusing the . Tim W. tjameswhite.com/blog ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ From pmw57 at xtra.co.nz Mon Mar 12 11:20:58 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 12 11:21:13 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> <009701c76448$af3382c0$bc08a8c0@nzto22> <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> Message-ID: <45F5A81A.1010306@xtra.co.nz> James Craig wrote: > Paul Wilkins wrote: > >> With the abbr design pattern, you encode the machine-readable info >> around the human-readable words. >>
T?l?c: > class="value">(514) 123-4568
>> >> http://microformats.org/wiki/abbr-design-pattern has more details on >> the abbre design pattern. > > > This is a misuse of abbr at best. > > See: open issue! 2007-01-26 > http://microformats.org/wiki/hcard-issues I also see that you are the author of that open issue, and that it's been rejected. The abbr design pattern is the currently accepted microformat method in which to provide machine readable information for human readable content, as it's defined in the TEL Type Definition at http://www.microformats.org/wiki/hcard-examples#3.3.1_TEL_Type_Definition my work phone, with voicemail: +1-213-555-1234 While the abbr element isn't being used strictly as it was originally intended, there are sufficient grounds to continue using it for the purpose of microformats. The purpose of the abbr design pattern is formally to - to make text that is human readable also formally machine readable So in this case, the "T?l?c" is readable to (french) humans, while the title="fax" is machine readable
T?l?c: (514) 123-4568
The stated situations where the abbr design pattern is to be avoided is when it's used - to re-encode human text or to hide data Which would make the following an incorrect use, as the type is being hidden from view
(514) 123-4568
I have yet to find a succinct example of re-encoding human text. Other solutions that have been tempting have been the use of namespaces, but they have long been considered to be harmful. So failing that, what else comes even close? The DFN element? -- Paul Wilkins -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From ezods.jjc at gmail.com Mon Mar 12 19:57:07 2007 From: ezods.jjc at gmail.com (Jon Clausen) Date: Mon Mar 12 19:57:09 2007 Subject: [uf-discuss] Geo Elevation Data Message-ID: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> I apologize if this has been been discussed before. I browsed through the wiki and the list archives and couldn't find any relevant threads or pages. So I joined the list to ask :-) I'm developing an app that makes heavy use of geo-spatial data, both lines and points. I'd like to incorporate the geo microformat for points, at minimum, however the coordinate data also includes the z-index (elevation) as well. My first question is whether elevation has been proposed as part of the geo draft specification? Adding the third dimension would seem natural and would add additional precision when adopted. My second question is whether or not, for line data, it is acceptable to include multiple latitude and longitude classes, in sequence, which make up the line in sequence or if there is a better way to do it? Thanks, - Jon P.S. - Thanks for the great presentation at SXSW today, Tantek and others who presented. It brought home for me some great possibilities that I was missing! From pmw57 at xtra.co.nz Mon Mar 12 20:24:41 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 12 20:24:46 2007 Subject: [uf-discuss] Geo Elevation Data References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> Message-ID: <004001c76527$85ca0e10$bc08a8c0@nzto22> From: "Jon Clausen" >I apologize if this has been been discussed before. I browsed through > the wiki and the list archives and couldn't find any relevant threads > or pages. So I joined the list to ask :-) Hi Jon, thakns for joining. It's always useful to receive more input on these things. > I'm developing an app that makes heavy use of geo-spatial data, both > lines and points. I'd like to incorporate the geo microformat for > points, at minimum, however the coordinate data also includes the > z-index (elevation) as well. > > My first question is whether elevation has been proposed as part of > the geo draft specification? Adding the third dimension would seem > natural and would add additional precision when adopted. Unfortunately the third dimension is being rejected at this time. However, if the vCard spec is updated to include an altitude component, then it will definately become a part of the hCard spec too. http://microformats.org/wiki/hcard-issues If it does get decided to add an altitude component, it'll be explored first on the brainstoming section. http://microformats.org/wiki/hcard-brainstorming#geo_improvements But at this particular stage, extensions to hCard/vCard are being currently rejected. > My second question is whether or not, for line data, it is acceptable > to include multiple latitude and longitude classes, in sequence, which > make up the line in sequence or if there is a better way to do it? What kind of use do you envisage web tools being able to use that line sequence information for? This may be a case where something greater than the Geo microformat (which is point specific) is required. -- Paul Wilkins From bewest at gmail.com Mon Mar 12 21:37:46 2007 From: bewest at gmail.com (Benjamin West) Date: Mon Mar 12 21:37:51 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <923a87360703090835j4cf1aa8au9918392a8cb8fdc3@mail.gmail.com> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> <923a87360703090835j4cf1aa8au9918392a8cb8fdc3@mail.gmail.com> Message-ID: <8ad71be30703122237t6d7cc31amf4476125a60bf5e0@mail.gmail.com> > > This is all relevant to existing specific-purpose date-time > > properties, [snip] > > What exactly would we want > > to do with a generic date apart from any specific context? > > Well, blog posts and articles online come to mind. They're normally > dated, yet there's no convention that states that "this is how you > should date an article". Rather than debate, why don't we just ask Bob for more information about what he's trying to do? Bob: can you give us some more examples of what you'd like to do, not just request a specific technique? As far as periodicals, we already have hAtom which includes mandatory dates. Blogs and articles, and other similar content, is can be marked up using hatom. As far as screen readers go: can anyone name some of the "more popular" screen readers so we can involve the authors in the semantic markup dialogue? Thanks, Ben From mdagn at spraci.com Tue Mar 13 17:15:01 2007 From: mdagn at spraci.com (Michael MD) Date: Mon Mar 12 22:14:27 2007 Subject: [uf-discuss] Geo Elevation Data References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> Message-ID: <003901c765d6$3393f610$116bacca@COMCEN> > Unfortunately the third dimension is being rejected at this time. However, > if the vCard spec is updated to include an altitude component, then it > will definately become a part of the hCard spec too. > http://microformats.org/wiki/hcard-issues I think altitude might be useful to some people ... eg a site about mountain climbing might want to mark up how high the tops of the mountains are as well as where they are. (and that information would probably have nothing to do with anyone's contact details!) From alexander.graf at deri.org Tue Mar 13 01:06:31 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Tue Mar 13 01:06:39 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <004001c76527$85ca0e10$bc08a8c0@nzto22> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> Message-ID: <69E321D4-621F-42EF-8FC7-DEF0A87E1012@deri.org> On 13.03.2007, at 04:57, Jon Clausen wrote: > I apologize if this has been been discussed before. I browsed through > the wiki and the list archives and couldn't find any relevant threads > or pages. So I joined the list to ask :-) Welcome to the list, Jon. On 13.03.2007, at 05:24, Paul Wilkins wrote: >> My first question is whether elevation has been proposed as part of >> the geo draft specification? Adding the third dimension would seem >> natural and would add additional precision when adopted. > > Unfortunately the third dimension is being rejected at this time. > However, if the vCard spec is updated to include an altitude > component, then it will definately become a part of the hCard spec > too. > http://microformats.org/wiki/hcard-issues > > If it does get decided to add an altitude component, it'll be > explored first on the brainstoming section. > http://microformats.org/wiki/hcard-brainstorming#geo_improvements > But at this particular stage, extensions to hCard/vCard are being > currently rejected. To clarify, the geo microformat is a 1:1 representation of the "geo" property in the vCard standard. That's why extensions to geo are rejected as well. I also would like to see a (maybe new) microformat which allowed for altitude at least but hopefully also for different projections, date systems and so on. There is way more to geographical coordinates than what geo offers. Jon, if you want to start creating a new geo-like format, I'll gladly help. You may want to look at the process (http://microformats.org/wiki/process) first. There are a few places you can start looking at, regarding what others have done: - http://microformats.org/wiki/thoughts-on-extending-the-geo- microformat (abandoned) - http://microformats.org/wiki/location-formats Hope that helps. Best regards, - Alex From romakimmy at gmail.com Tue Mar 13 05:22:42 2007 From: romakimmy at gmail.com (Kim Franch) Date: Tue Mar 13 05:22:57 2007 Subject: [uf-discuss] hCard email & type properties In-Reply-To: References: <00c501c76455$8fa4abc0$bc08a8c0@nzto22> <005701c7652c$3ce2c750$116bacca@COMCEN> Message-ID: Point taken. Thank you for the further explaination Scott. Back to the drawing board for me. Cheers, Kim > > If I right-click on a URL and choose "Add Link to Bookmarks" in my > browser, I should ideally get the same link that I would get if I > clicked on my microformat parser and imported the hCard. It sounds > like I'm getting a different link, that you're presenting different > content to different user agents, which is less than ideal. > > > If this info is > > included in the hCard, why would a redirect link be more useful to > > machines > > hCards are intended for machines to parse. Humans can read the > content without hCards, but machines can't, so what humans see in > their browser is what I mean by "human-readable content," though > obviously humans are eventually using the hCard content as well. In > your example, the human-readable (browser-rendered) content is less > useful than the machine-readable hCard. It's a subtle difference, as > both links should eventually end up in the same place, but we should > avoid these differences where possible. From ezods.jjc at gmail.com Tue Mar 13 09:28:10 2007 From: ezods.jjc at gmail.com (Jon Clausen) Date: Tue Mar 13 09:28:13 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <004001c76527$85ca0e10$bc08a8c0@nzto22> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> Message-ID: <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> > What kind of use do you envisage web tools being able to use that line > sequence information for? > > This may be a case where something greater than the Geo microformat (which > is point specific) is required. At the current time, that's difficult. I'll try to give a couple of examples, though. The app I'm developing has the ability to upload and import GPS data from 25 different formats common to the major GPS manufacturers. From there it allows you to organize, share, and export that data (points and routes) as well as to export it out in any of those formats. The common data which is standard across most of the formats is Lat, Lon, and Elevation. Routes are stored as a collection of waypoints and are marked up differently, but are the same basic data - albeit in sequence. Along the way, I'm trying to plug-in the API to other tools which make use of spatial data such as Flickr. Routes are a natural progression from points since they communicate time as well as space. If the ability were there for a user to geo-tag their photos, and map those photos to routes or trails that they have taken, you might have the ability to share a "virtual tour" of their trip in a mapped sequence or exploration through current tools like Google Earth and progress in sequence. Another example might be a of a Flickr user who sees a series of vacation photos organized into a route and wants to export that route and locations to the Spotstor (my app) API for export into their GPS. As noted before, Mountain climbing or hiking might be an example of this. Another example might be persons who might want to pass directions to each other to meet up in a large corporate campus - i.e. - "here's my cube from where you are". The 3rd dimension would be helpful there as well in multi-level buildings. As I was in the "Spatial Reality" panel here at SXSW a couple of days ago, it kind of hit me that with the work Google is doing around mapping the 3rd dimension of cities and topography could pose display problems for data that doesn't contain a z-index. Without the 3rd dimension, mapping those points using Google earth or, perhaps in the future, through Google maps, might cause the waypoint to be displayed inside an object instead of at the correct elevation. Hope that helps to clarify. I can certainly submit a proposal for the route format - which would probably be best served by an ordered list containing separate geo elements:

Latitude: -83.0000 Longitude: 43.0000 Elevation: 2012.0000
etc....
-Jon From danny.ayers at gmail.com Tue Mar 13 09:35:42 2007 From: danny.ayers at gmail.com (Danny Ayers) Date: Tue Mar 13 09:35:44 2007 Subject: [uf-discuss] Knowee: XFN/hCard community project Message-ID: <1f2ed5cd0703131035k97dc2e7wff258c0c628e2caf@mail.gmail.com> The Semantic Web Education and Outreach group (SWEO) recently nominated four community projects it would support. One is particularly relevant over here: [[ knowee is a distributed, web-based contact organizer. It would be largely bootstrapped via the XFN and hCard microformats, but uses SPARQL (or maybe just a simple RDF lib) for application functionality and RDF for information integration. ]] More info : http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/knowee Cheers, Danny. -- http://dannyayers.com From scott at randomchaos.com Tue Mar 13 10:36:51 2007 From: scott at randomchaos.com (Scott Reynen) Date: Tue Mar 13 10:36:55 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> Message-ID: <0BDC6C49-3483-486E-9828-4476E380357B@randomchaos.com> On Mar 13, 2007, at 12:28 PM, Jon Clausen wrote: > Without the 3rd dimension, mapping those points using Google earth or, > perhaps in the future, through Google maps, might cause the waypoint > to be displayed inside an object instead of at the correct elevation. > > Hope that helps to clarify. I can certainly submit a proposal for > the route format Please follow the process: http://microformats.org/wiki/process You've gone through the "Why?" here, so the next step is to document current behavior. Who is currently publishing elevations, and how are they doing it? Are there any established formats for this type of information? After answering questions like these, we should look at the possibility of using existing markup standards to cover the information, including HTML structures and existing microformats. Only when we've established that existing markup standards fall short of solving the problem of standardizing real-world publishing should we start thinking about new markup. Because old markup tends to be adopted more readily than new markup, and adoption is what makes standards useful, new markup should always be a last resort. Peace, Scott From pmw57 at xtra.co.nz Tue Mar 13 10:58:35 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Tue Mar 13 10:58:51 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <445373.5808.qm@web30805.mail.mud.yahoo.com> References: <445373.5808.qm@web30805.mail.mud.yahoo.com> Message-ID: <45F6F45B.8020702@xtra.co.nz> Tim White wrote: >----- Original Message ---- >>From Ara > >On 3/12/07, James Craig wrote: > > >>Paul Wilkins wrote: >> >> >> >>>With the abbr design pattern, you encode the machine-readable info >>>around the human-readable words. >>>
T?l?c: >>class="value">(514) 123-4568
>>> >>> > > > >>This is a misuse of abbr at best. >> >>See: open issue! 2007-01-26 >>http://microformats.org/wiki/hcard-issues >> >> > > > >>Okay, so what does a guy do in a case like this then? >> >> > >What about something along the lines of: > >
Telec: (514) 123-4568
> >Title is a valid HTML attribute and this avoids abusing the . > > The possibility of using the title attribute to hold generic machine readable information was considered and rejected. The title attribute is already commonly used on many elements today. If people were to add a microformat to their page, they would have to remove all title attributed content except for that which they specifically intended to be the machine readable information. This then becomes an abuse of the title attribute and as such is not allowed. Another reason for discarding the idea was that it makes it too easy for people then to hide information. If someone is not willing to make the information available in plain text, then that information shouldn't be used.This is why we people shouldn't be encouraged to store information invisibly because that just leads to bad things. Restricting the title attribute for microformatted information to just the abbr element itself was considered and allowed, because that element at least, is purpose built to show a different representation of the information within it, and that's why it's become so useful with dates and other content, to allow human readable content with a machine understandable representation. When it comes to languages other than English though, this is where things get tricky, and is covered in the FAQ at http://microformats.org/wiki/faq#Q:_How_do_microformats_breach_language_barriers.3F Effectively, the language barrier is a pre-existing unsolved problem. While it's fine for class names to be represented in English, what happens when the readable content is used as keyword data. We are left with one of two options. Either the readable data needs to remain as English, or some other way needs to be found to provide a representation of that non-english data in an english form. Currently there hasn't been a more appropriate answer to this than the abbr design pattern, and it is possible to justify. The computer is able to understand only a very small number of terms, and each of those terms can be expressed in a wide number of human readable formats. So what we're doing with the abbr design pattern is to take one of these vast number of human readable formats and abbreviate all of those possibilities down to one common computer understandable term. T?l?c: The only viable alternatives are either to spell it out in full, T?l?c (Fax): Or to hide the english form of the word T?l?c Fax: This is one of those situations where whateveryou do, you're guilty of something. -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From pmw57 at xtra.co.nz Tue Mar 13 12:24:19 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Tue Mar 13 12:24:24 2007 Subject: [uf-discuss] hCard email & type properties References: <00c501c76455$8fa4abc0$bc08a8c0@nzto22><005701c7652c$3ce2c750$116bacca@COMCEN> Message-ID: <005501c765ad$95197690$bc08a8c0@nzto22> From: "Kim Franch" > Point taken. Thank you for the further explaination Scott. Back to the > drawing board for me. What we've taken to doing is to provide the proper url in the href, so that tools can make good use of it, and use the onmousedown event, so that should someone click on it, the url is rewritten to incorporate clickthrough data. -- Paul Wilkins From ezods.jjc at gmail.com Tue Mar 13 12:48:31 2007 From: ezods.jjc at gmail.com (Jon Clausen) Date: Tue Mar 13 12:48:34 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <0BDC6C49-3483-486E-9828-4476E380357B@randomchaos.com> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <0BDC6C49-3483-486E-9828-4476E380357B@randomchaos.com> Message-ID: <1b42308f0703131348ye81ed76l39f8b44fbb520739@mail.gmail.com> On 3/13/07, Scott Reynen wrote: > On Mar 13, 2007, at 12:28 PM, Jon Clausen wrote: > > > Without the 3rd dimension, mapping those points using Google earth or, > > perhaps in the future, through Google maps, might cause the waypoint > > to be displayed inside an object instead of at the correct elevation. > > > > Hope that helps to clarify. I can certainly submit a proposal for > > the route format > > Please follow the process: > > http://microformats.org/wiki/process Will do. Thanks for your help. > You've gone through the "Why?" here, so the next step is to document > current behavior. Who is currently publishing elevations, and how > are they doing it? Are there any established formats for this type > of information? After answering questions like these, we should look > at the possibility of using existing markup standards to cover the > information, including HTML structures and existing microformats. > Only when we've established that existing markup standards fall short > of solving the problem of standardizing real-world publishing should > we start thinking about new markup. Because old markup tends to be > adopted more readily than new markup, and adoption is what makes > standards useful, new markup should always be a last resort. Absolutely. I'll make sure that is all documented. From alexander.graf at deri.org Wed Mar 14 00:30:43 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Wed Mar 14 00:30:54 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> Message-ID: > Hope that helps to clarify. I can certainly submit a proposal for > the route format - which would probably be best served by an ordered > list containing separate geo elements: > >
>
> Latitude: -83.0000 > Longitude: 43.0000 > Elevation: 2012.0000 >
> etc.... >
Hi Jon, best if you read the process on the wiki first. And as geo is just used for encapsulating Lat/Lon values in hCards, I don't think reusing is a good idea. It will change according to the vCard standard. Best, Alex From news4e71 at yahoo.com Wed Mar 14 14:25:49 2007 From: news4e71 at yahoo.com (LuigiG) Date: Wed Mar 14 14:25:51 2007 Subject: [uf-discuss] Logging information Message-ID: <984956.74474.qm@web58210.mail.re3.yahoo.com> Hi, is there a microformat specification for application/server logs? Typical structure: [DTM stamp] [Severity] [Message] Example: 2007-03-03.13:43:21 INFO Server was started But then with each element tagged with an appropriate class. Any input would be appreciated, LuigiG ____________________________________________________________________________________ Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather From pmw57 at xtra.co.nz Wed Mar 14 14:40:10 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Wed Mar 14 14:40:21 2007 Subject: [uf-discuss] Logging information Message-ID: <003c01c76689$b91a4dd0$bc08a8c0@nzto22> From: "LuigiG" > is there a microformat specification for > application/server logs? > Typical structure: > > [DTM stamp] [Severity] [Message] > > Example: > > 2007-03-03.13:43:21 INFO Server was started > > But then with each element tagged with an appropriate > class. What is the problem that you require a solution for? -- Paul Wilkins From scott at randomchaos.com Wed Mar 14 15:32:27 2007 From: scott at randomchaos.com (Scott Reynen) Date: Wed Mar 14 15:32:30 2007 Subject: [uf-discuss] Logging information In-Reply-To: <984956.74474.qm@web58210.mail.re3.yahoo.com> References: <984956.74474.qm@web58210.mail.re3.yahoo.com> Message-ID: <17014D2E-6037-4A5F-B6B3-38BCA6D09209@randomchaos.com> On Mar 14, 2007, at 5:25 PM, LuigiG wrote: > Hi, > > is there a microformat specification for > application/server logs? > Typical structure: > > [DTM stamp] [Severity] [Message] > > Example: > > 2007-03-03.13:43:21 INFO Server was started > > But then with each element tagged with an appropriate > class. > > Any input would be appreciated, Hi Luigi, There is currently no microformat for that specifically, but it looks like what you're logging is an event, so you can probably publish it with hCalendar: http://microformats.org/wiki/hcalendar For example:

2007-03-03.13:43:21 INFO Server was started

If you still want to talk about a new microformat, that probably belongs on the -new list: http://microformats.org/mailman/listinfo/microformats-new But I'd encourage you to try using hCalendar. Peace, Scott From robertc at gmail.com Thu Mar 15 05:56:23 2007 From: robertc at gmail.com (Rob Crowther) Date: Thu Mar 15 05:56:29 2007 Subject: [uf-discuss] Logging information In-Reply-To: <17014D2E-6037-4A5F-B6B3-38BCA6D09209@randomchaos.com> References: <984956.74474.qm@web58210.mail.re3.yahoo.com> <17014D2E-6037-4A5F-B6B3-38BCA6D09209@randomchaos.com> Message-ID: <3ce2ebd20703150656m4032bb5ap3db4bda5189f668a@mail.gmail.com> On 14/03/07, Scott Reynen wrote: > There is currently no microformat for that specifically, but it looks > like what you're logging is an event, so you can probably publish it > with hCalendar: > I was thinking it was more like hAtom: http://microformats.org/wiki/hatom Since that has all the elements of hCalendar plus it has a category and also author which might conceivably be the server name. Plus hAtom seems more like the concept of an event log - ie. there's an implicit association between the events. Rob From alwinblok at gmail.com Thu Mar 15 06:28:11 2007 From: alwinblok at gmail.com (Alwin Blok) Date: Thu Mar 15 06:28:26 2007 Subject: [uf-discuss] include pattern : including table data Message-ID: <334E7B69-ED14-4487-A919-AF539CCACBC8@gmail.com> Hello all. I'm new to the mailinglist; I'm a student and freelance designer/ developer. I have a question about the include pattern: anchor elements are not allowed in all elements: ie using an anchor element to include extra table data (rows) will result in invalid xhtml. ie.
is not valid. I suppose we could work around this by using the title attribute along with the class="include" on almost all elements. ie.
is valid. The title attribute set too "#an_id", however does not indicate a reference to an other element, which is a problem. Any thoughts/ suggestions ? Regards -Alwin From pmw57 at xtra.co.nz Thu Mar 15 12:25:17 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Thu Mar 15 12:25:23 2007 Subject: [uf-discuss] include pattern : including table data References: <334E7B69-ED14-4487-A919-AF539CCACBC8@gmail.com> Message-ID: <006801c76740$0bec1e60$bc08a8c0@nzto22> From: "Alwin Blok" > I have a question about the include pattern: > anchor elements are not allowed in all elements: ie using an anchor > element to include extra table data (rows) will result in invalid xhtml. > ie.
is not valid. > > I suppose we could work around this by using the title attribute along > with the class="include" on almost all elements. > ie.
is > valid. > > The title attribute set too "#an_id", however does not indicate a > reference to an other element, which is a problem. Any thoughts/ > suggestions ? The include pattern is not going to change how information is presented on the screen. The purpose of the include pattern is to allow you to reuse microformat information that's already on the page. The only effect that the include pattern has is on parsers looking through the page for microformat information. For example, if you have information that an hcard could use, then later on in the page you have address details for them, their first hcard information can be reused (when microformat info is extracted) without having to redisplay that info on the page again.
Paul Wilkins
... other stuff ...
The place where I live is 123 Evergreen Terrace.
If you can provide an example of what you're wanting to display on the page, we can then help with examples of how to effectively mark it up as a microformat. -- Paul Wilkins From brian.suda at gmail.com Thu Mar 15 12:34:48 2007 From: brian.suda at gmail.com (Brian Suda) Date: Thu Mar 15 12:34:50 2007 Subject: [uf-discuss] include pattern : including table data In-Reply-To: <334E7B69-ED14-4487-A919-AF539CCACBC8@gmail.com> References: <334E7B69-ED14-4487-A919-AF539CCACBC8@gmail.com> Message-ID: <21e770780703151334m146e7eeyce71e28e91286e6@mail.gmail.com> On 3/15/07, Alwin Blok wrote: > Hello all. > > I'm new to the mailinglist; I'm a student and freelance designer/ > developer. --- hello, welcome to the list > I suppose we could work around this by using the title attribute > along with the class="include" on almost all elements. > ie.
> is valid. --- there is a better, more semantic way. Tables have several accessibility 'hooks' they allow for axis, header, id, and other attributes to create relationships between two cells. Unfortunately, i can't seem to find any examples about this on the wiki, and the example pages no longer seem to exist. I know the new microformats book does cover all of this indepth, hopefully we can get an example on the wiki. Do you have a URL you could post here so we can help you mark-it-up? -brian -- brian suda http://suda.co.uk From news4e71 at yahoo.com Thu Mar 15 13:40:14 2007 From: news4e71 at yahoo.com (LuigiG) Date: Thu Mar 15 13:40:17 2007 Subject: [uf-discuss] Logging information Message-ID: <902799.13095.qm@web58213.mail.re3.yahoo.com> Thank you guys. hCalendar and hAtom seem pretty close to what I'm looking for. The idea is, basically, to provide: a) structured embedding of log information in web based monitoring tools. (rather than just "a lump of text") b) exposal of a log as a set of RSS feeds, one for each severity threshold (e.g. anything from WARN up) which could be subscribed to by both "human targeted" readers and other types of tools, such as SMS alert bots or report generators (hence the value of log metadata). So the two formats look very interesting. We also have an app that generates a hierarchical log (currently viewable via a custom tree-view gui), so I need to figure out whether nesting is possible/legal in hClendar or hAtom. Tentative (very tentative) example:

2007-03-03.13:43:21 INFO Task 123 running

2007-03-03.13:43:30 DEBUG Sending File FILE1.DAT

2007-03-03.13:43:38 DEBUG Sending File FILE2.DAT

The alternative would be to flatten the structure, (kind of a left outer join), but that's not my favorite solution. Thanks again, Luigi ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL From john at westciv.com Thu Mar 15 14:03:45 2007 From: john at westciv.com (John Allsopp) Date: Thu Mar 15 14:03:54 2007 Subject: [uf-discuss] include pattern : including table data In-Reply-To: <21e770780703151334m146e7eeyce71e28e91286e6@mail.gmail.com> References: <334E7B69-ED14-4487-A919-AF539CCACBC8@gmail.com> <21e770780703151334m146e7eeyce71e28e91286e6@mail.gmail.com> Message-ID: <2EC8385C-38B5-43A0-A3E9-109637ED36DB@westciv.com> Brian, >> Hello all. >> >> I'm new to the mailinglist; I'm a student and freelance designer/ >> developer. > > --- hello, welcome to the list > >> I suppose we could work around this by using the title attribute >> along with the class="include" on almost all elements. >> ie.
>> is valid. > > --- there is a better, more semantic way. Tables have several > accessibility 'hooks' they allow for axis, header, id, and other > attributes to create relationships between two cells. > > Unfortunately, i can't seem to find any examples about this on the > wiki, and the example pages no longer seem to exist. > > I know the new microformats book does cover all of this indepth, > hopefully we can get an example on the wiki. I'm starting a new column at digital web very soon "code sharp" - this might be a great thing to kick off with. (for those who don't know, I'm the guy who wrote the book Brian is referring to - but much better, Brian Tech Edited it) http://microformatique.com/book There's also a great online tool for building table based hCalendars, http://dmitry.baranovskiy.com/work/csc/ very cool john p.s. (out march 26) pps sorry for the slightly advertisey post j > > Do you have a URL you could post here so we can help you mark-it-up? > > -brian > > -- > brian suda > http://suda.co.uk > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From john at westciv.com Thu Mar 15 15:23:14 2007 From: john at westciv.com (John Allsopp) Date: Thu Mar 15 15:23:22 2007 Subject: [uf-discuss] Microformats Process flowchart 0.1 In-Reply-To: <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> Message-ID: <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> Hi all, as part of the workshop at IA Summit on structured data, where I am doing a session on ufs, I have put together a flowchart to introduce people to the all important process of developing microformats. [1] I've not uploaded it to the wiki yet as 1. it might not be at all appropriate 2. it probably needs a lot of work, and as such, may well confuse more than it helps - and as it is not really editable, we can't really use the wiki process to do that. There's also an omnigraffle version you can download [2] if you want to fix it up a bit (or just email me changes you think need making). Sorry that its in this format - I only have the standard version of graffle, so can't export as SVG - anyone who cares to do so, please feel free, and send it back. I've tried to capture the current narrative description at the wiki [3] in a formal flowchart kinda way (note, 20 years since comp sci, flow chart may be completely wrong) I'd be interested to hear people's thoughts as to whether it is useful, and what needs changing/fixing thanks in advance john [1] http://microformatique.com/process/process.html [2] http://microformatique.com/process/process.zip [3] http://microformats.org/wiki/process John Allsopp style master :: css editor :: http://westciv.com/style_master about me :: http://johnfallsopp.com Web Directions Conferences :: http://webdirections.org My Microformats book :: http://microformatique.com/book From dmitry.baranovskiy at gmail.com Thu Mar 15 16:39:46 2007 From: dmitry.baranovskiy at gmail.com (Dmitry Baranovskiy) Date: Thu Mar 15 16:39:56 2007 Subject: [uf-discuss] Microformats Process flowchart 0.1 In-Reply-To: <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> Message-ID: <62FDF9BB-112C-496F-805C-028A22B7024F@gmail.com> SVG version is on http://dmitry.baranovskiy.com/process.svg Give me a buzz if you need more. Cheers, Dmitry From alwinblok at gmail.com Thu Mar 15 18:34:34 2007 From: alwinblok at gmail.com (Alwin Blok) Date: Thu Mar 15 18:34:52 2007 Subject: [uf-discuss] include pattern : including table data In-Reply-To: <21e770780703151334m146e7eeyce71e28e91286e6@mail.gmail.com> References: <334E7B69-ED14-4487-A919-AF539CCACBC8@gmail.com> <21e770780703151334m146e7eeyce71e28e91286e6@mail.gmail.com> Message-ID: <357D1A6D-C8E2-4077-9BEC-3C09A9177E48@gmail.com> Op 15-mrt-2007, om 21:34 heeft Brian Suda het volgende geschreven: >> I suppose we could work around this by using the title attribute >> along with the class="include" on almost all elements. >> ie.
>> is valid. > > --- there is a better, more semantic way. Tables have several > accessibility 'hooks' they allow for axis, header, id, and other > attributes to create relationships between two cells. > Do you have a URL you could post here so we can help you mark-it-up? > > -brian Hmm, I realise now, that this is indeed, not really a problem with general use of the include pattern. Sorry for going off-topic, but let me explain my question: I am building a templating system for skinning, and editing data structures. For this, I am using elements containing optional includes and choice includes (as templates), when I noticed a resemblance with the markup of the include pattern. A simple gui for a list of records could look like this: Add another record..

First Name Last Name

Add record.. Clicking "Add record" clones the referred item, binds it to backend data and replaces the anchor. I think this is related to microformats, as it actually describes a grammar of a (compound) microformat. I need to specify these grammars, and I am trying to find a format for the specifications. Regards, -Alwin From thom at ts0.com Fri Mar 16 09:39:57 2007 From: thom at ts0.com (Thom Shannon) Date: Fri Mar 16 09:40:08 2007 Subject: [uf-discuss] Microformats Process flowchart 0.1 In-Reply-To: <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> Message-ID: <45FAD66D.6030003@ts0.com> you could create it in dot format and post that on the wiki, its very easy to edit and there's a plugin for media wiki that will render it out. Would be great to be able to illustrate various structures on there, processes and object relational diagrams etc http://www.wickle.com/wikis/index.php/Graphviz_extension John Allsopp wrote: > Hi all, > > as part of the workshop at IA Summit on structured data, where I am > doing a session on ufs, I have put together a flowchart to introduce > people to the all important process of developing microformats. [1] > I've not uploaded it to the wiki yet as > > 1. it might not be at all appropriate > 2. it probably needs a lot of work, and as such, may well confuse more > than it helps - and as it is not really editable, we can't really use > the wiki process to do that. > > There's also an omnigraffle version you can download [2] if you want > to fix it up a bit (or just email me changes you think need making). > Sorry that its in this format - I only have the standard version of > graffle, so can't export as SVG - anyone who cares to do so, please > feel free, and send it back. > > I've tried to capture the current narrative description at the wiki > [3] in a formal flowchart kinda way (note, 20 years since comp sci, > flow chart may be completely wrong) > > I'd be interested to hear people's thoughts as to whether it is > useful, and what needs changing/fixing > > thanks in advance > > john > > [1] http://microformatique.com/process/process.html > [2] http://microformatique.com/process/process.zip > [3] http://microformats.org/wiki/process > > John Allsopp > > style master :: css editor :: http://westciv.com/style_master > about me :: http://johnfallsopp.com > Web Directions Conferences :: http://webdirections.org > My Microformats book :: http://microformatique.com/book > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From costello at mitre.org Fri Mar 16 11:12:43 2007 From: costello at mitre.org (Costello, Roger L.) Date: Fri Mar 16 11:13:07 2007 Subject: [uf-discuss] Making Local Knowledge Globally Useful [was: Zen of Microformats] Message-ID: Hi Folks, A couple weeks back we had an excellent discussion on how Microformats enable information to be both resolutely local and globally useful. I have captured the discussion on a wiki page: http://www.xfront-wiki.com/wiki/index.php?title=Making_Local_Knowlege_G lobally_Useful I invite you to participate in evolving this article. /Roger From lists at allinthehead.com Sat Mar 17 09:26:39 2007 From: lists at allinthehead.com (Drew McLellan) Date: Sat Mar 17 09:26:47 2007 Subject: [uf-discuss] Microformats Process flowchart 0.1 In-Reply-To: <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> Message-ID: <8E2DF2C8-6935-499F-9561-75C46EF7AF77@allinthehead.com> On 15 Mar 2007, at 23:23, John Allsopp wrote: > I'd be interested to hear people's thoughts as to whether it is > useful, and what needs changing/fixing Looks great, John. Very useful for visualising the process. drew. From john at westciv.com Sat Mar 17 14:35:00 2007 From: john at westciv.com (John Allsopp) Date: Sat Mar 17 14:35:12 2007 Subject: [uf-discuss] Microformats Process flowchart 0.1 In-Reply-To: <8E2DF2C8-6935-499F-9561-75C46EF7AF77@allinthehead.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> <8E2DF2C8-6935-499F-9561-75C46EF7AF77@allinthehead.com> Message-ID: <96468F7A-4661-4A24-A26F-CDDCED8C9856@westciv.com> Thanks Drew, > >> I'd be interested to hear people's thoughts as to whether it is >> useful, and what needs changing/fixing > > Looks great, John. Very useful for visualising the process. I've approached the uf process in detail a couple of times. Once when working on the tagcloud stuff (and despite linking each step of the way to the process, still seem to have effed it up.) So, take two was for my bok, where we decided a chapter on the process was important for contextualizing, despite the significant majority of people interested in ufs being unlikely to ever develop a uf - the process is a key part of what makes something a microformat, and when I speak it is often question #1 - "how does something become a uf"? Actually, recently, for the workshop I am involved in at IA Summit, I felt it important to cover the process, and so revisited the process page. I've found each time it some work to really understand the process in detail (hence my original ^&*# up with tagclouds) and even with the flowchart, I am not sure I've got it 100% right :-/ I know it comes up quite a bit, particularly with those interested in proposing a microformat, where we typically refer them off to the process. I hope something visual like this can help a bit. But of course, it has to be right! thank again john > > drew. > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From bewest at gmail.com Sat Mar 17 19:28:00 2007 From: bewest at gmail.com (Benjamin West) Date: Sat Mar 17 19:28:02 2007 Subject: documenting techniques: Re: [uf-discuss] Logging information Message-ID: <8ad71be30703172028y5a346cf3hca5ee5e7b6254fca@mail.gmail.com> On 3/15/07, Rob Crowther wrote: > On 14/03/07, Scott Reynen wrote: > > There is currently no microformat for that specifically, but it looks > > like what you're logging is an event, so you can probably publish it > > with hCalendar: > > > I was thinking it was more like hAtom: > > http://microformats.org/wiki/hatom > > Since that has all the elements of hCalendar plus it has a category > and also author which might conceivably be the server name. Plus > hAtom seems more like the concept of an event log - ie. there's an > implicit association between the events. > > Rob This is great advice from both Rob and Scott. I think documenting techniques should be a successful goal for the microformats community (because it helps to document the need, or lack thereof, for new formats). I couldn't find a great spot on the wiki, so I satisficed on -advocacy#hatom: . Thanks, Ben West From andy at pigsonthewing.org.uk Thu Mar 8 14:11:52 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:23 2007 Subject: [uf-discuss] [Zen of Microformats] Two Fundamental Principles of Information Design In-Reply-To: <45F07183.40907@iandavis.com> References: <45F060F0.1000602@iandavis.com> <923a87360703081143r79528bf1v3f449dedfb6b1fa2@mail.gmail.com> <45F07183.40907@iandavis.com> Message-ID: In message <45F07183.40907@iandavis.com>, Ian Davis writes >On 08/03/2007 19:43, Ara Pehlivanian wrote: >> What I think your contrast of microformats' bottleneck with the web's >> free growth is missing is the notion that there indeed /was/ a >> "bottleneck" in the development of the web in the form of Tim >> Berners-Lee. >Maybe I'm misunderstanding but you appear to be saying that creation of >each microformat is equivalent to creating HTML, i.e. a set of useful >elements people can use for creative expression. Under the microformats >process that effort needs to be centralised to prevent name collision, >semantic drift and duplication of effort. There's no way to allow >parallel development and then work out how to coordinate differences later. > >This means there's a limit to the scalability of the mf development process. I wonder if the issue isn't connected to the way microformats have been developed on a relatively wide-scale format (e.g. hCard) rather than first focussing on smaller components ("telephone numbers, say, then postal addresses, and personal/ organisational names; then combining these). >I think the agreements can occur in parallel between interested and >motivated parties. But that's not the impression I get of the >microformats process. It isn't a microformat until it's blessed by the >mf community. I'm not sure that it's the "community" whose blessing is relevant. >Here's a great microformat that's been developed outside the mf community: > >http://selfdescription.org/ > >Has anyone here heard of it, evaluated it or have an opinion on it? I think there should be a page on the Wiki where such initiatives are listed, and, if appropriate, critiqued. I have no confidence that such a page would be allowed. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Thu Mar 8 14:22:49 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:24 2007 Subject: [uf-discuss] SVG hCard example; sharing profiles? In-Reply-To: <1f2ed5cd0703080359l5b07a3bco87391300fddbac69@mail.gmail.com> References: <1f2ed5cd0703080359l5b07a3bco87391300fddbac69@mail.gmail.com> Message-ID: In message <1f2ed5cd0703080359l5b07a3bco87391300fddbac69@mail.gmail.com>, Danny Ayers writes >I couldn't find an example of microformats used in SVG, so I made one >http://dannyayers.com/misc/microformats/hcard-svg Interestingly, "operator" doesn't detect that (neither does Tails) -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 9 13:56:44 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:25 2007 Subject: [uf-discuss] Participation of specialists (Was: Not all semantic HTML is a microformat) In-Reply-To: <45F0A3B1.3000501@iandavis.com> References: <45F060F0.1000602@iandavis.com> <923a87360703081143r79528bf1v3f449dedfb6b1fa2@mail.gmail.com> <45F07183.40907@iandavis.com> <45F0A3B1.3000501@iandavis.com> Message-ID: <8yiF1ICcgd8FFwbQ@pigsonthewing.org.uk> In message <45F0A3B1.3000501@iandavis.com>, Ian Davis writes >>selfdescription.org If nothing else, that seems very badly named. >Anyone on the microformats list interested in collection description? >Maybe there are some librarians or archivists. If there aren't then it >appears to be impossible to make progress under the microformats process. We have a similar problem with "species" - a few, but not enough, biological taxonomists. Not least, as outlined previously, because the existing fora are off-putting to people with a specialist interest in one, rather than a generic interest on all, microformats. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 9 13:58:29 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:26 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <45F0A1ED.3510.2001717@bjonkman.sobac.com> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> Message-ID: <0ikHRhCFid8FFwbs@pigsonthewing.org.uk> In message <45F0A1ED.3510.2001717@bjonkman.sobac.com>, Bob Jonkman writes >Andy Mabbett suggested a class of "dtstamp" which comes closer to what >I intend, but the iCalendar property DTSTAMP is specifically meant to >indicate when an iCalendar object was created, which is not the case >here. Fair enough; I stand corrected. >Following the design pattern for dates, I think we need a semantic >classname such as "datetime" Agreed. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 9 14:02:51 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:26 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <45F129FE.8080306@xtra.co.nz> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> <45F129FE.8080306@xtra.co.nz> Message-ID: <2CHHp5CLmd8FFwYg@pigsonthewing.org.uk> In message <45F129FE.8080306@xtra.co.nz>, Paul Wilkins writes > you might write the date as 4/7/76 and force the reader to find and >use the abbreviation, but as someone who cares enough to create a >datetime design pattern, it should be obvious that writing the date as >July 4, 1776 solves the problem. That's not always going to be feasible; consider tabular data, or verbatim quotations for instance. >Another trouble is that with the arbitrary datetime pattern in use, how >can the machine benefit from that information. It's not immediately >clear. It's not just the machines that might benefit. A semantically marked-up date can be presented according to the users preferences. Given 2007-03-04, you might prefer to see March 4th 2007, where I prefer 4 March 2007 (see, for comparison, the user setting for dates in Wikipedia). -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 9 14:08:15 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:27 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <45F133AB.80205@xtra.co.nz> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> <45F133AB.80205@xtra.co.nz> Message-ID: In message <45F133AB.80205@xtra.co.nz>, Paul Wilkins writes >>This is for both for screen readers and disabiguation of dates such as >>3/2/2006 or 02-03-06. That's an important consideration. >As I'm to believe, screen readers will read out both parts of the date >information. As such, having the title as 4 July 1776 will mean the >screen reader will read >"The Constitution of 4 7 76 4 July 1776" Behaviour of inadequate user-agents should not be a driving factor; for all we know, a user agent with better behaviour might be released next week, or next month, or... Our responsibility is to publish valid, semantically-meaningful markup, not to pander to the former. >As the title is currently for screen readers or to disambiguate the >date, it should be kept in a human understandable format. >The Constitution of 4/7/76 Then why doesn't that apply to dtstart and dtend, for example? >There is some very useful information from the Manual of Style on the >formatting of dates and numbers. >http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28dates_and_numb >ers%29 > >The following is a direct quote of the relevant parts. > > > Incorrect date formats [...] That's "incorrect" according to the pretences of Wikipedia's administrators; not by any other authority. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 9 14:12:45 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:28 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> Message-ID: In message <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com>, Ara Pehlivanian writes >I've always had trouble with the idea of using to mark up dates >because semantically, it isn't expressing an abbreviation of any sort. That's particularly true of: 30 March which is an abomination (and an accessibility disaster) which I have vowed ever to use on web pages under my control. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Sun Mar 11 11:37:40 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:29 2007 Subject: [uf-discuss] hCard email & type properties In-Reply-To: References: Message-ID: In message , Kim Franch writes >random@foo .com foo .com is registered; please use "example.com", which is reserved for such purposes, for your examples. See: and RFC 2606, Section 3: Thank you. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Sun Mar 11 17:28:39 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:29 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> Message-ID: <8blVPF7HzK9FFwBx@pigsonthewing.org.uk> In message <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com>, Ara Pehlivanian writes >Tel.: (514) 123-4567 >Fax: (514) 123-4568 > >Yet with the required "voice"/"fax" types it ends up like this: > >Voice Tel.: (514) 123-4567 >Fax Fax: (514) 123-4568 > >or in the French version of the page: > >Voice T?l.: (514) 123-4567 >Fax T?l?c.: (514) 123-4568 You might use: Tel Fax and: T?l T?l?c Though there are concerns that that's an abuse of "abbr". -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Mon Mar 12 12:14:01 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:30 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <45F5A81A.1010306@xtra.co.nz> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> <009701c76448$af3382c0$bc08a8c0@nzto22> <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> <45F5A81A.1010306@xtra.co.nz> Message-ID: In message <45F5A81A.1010306@xtra.co.nz>, Paul Wilkins writes >>>
T?l?c: >>class="value">(514) 123-4568
>> This is a misuse of abbr at best. >> >> See: open issue! 2007-01-26 >> http://microformats.org/wiki/hcard-issues >I also see that you are the author of that open issue, and that it's >been rejected. Rejected with a request for further information, and subsequently re-opened. >The abbr design pattern is the currently accepted microformat method in >which to provide machine readable information for human readable >content, >as it's defined in the TEL Type Definition at >http://www.microformats.org/wiki/hcard-examples#3.3.1_TEL_Type_Definitio>n >While the abbr element isn't being used strictly as it was originally >intended, there are sufficient grounds to continue using it for the >purpose of microformats. Can you cite evidence that it's "currently accepted" for non-English content, as in the above example; or clarify those "sufficient grounds" for its use in such cases, please? -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Tue Mar 13 00:01:16 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:31 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <004001c76527$85ca0e10$bc08a8c0@nzto22> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> Message-ID: In message <004001c76527$85ca0e10$bc08a8c0@nzto22>, Paul Wilkins writes >> My first question is whether elevation has been proposed as part of >> the geo draft specification? Adding the third dimension would seem >> natural and would add additional precision when adopted. > >Unfortunately the third dimension is being rejected at this time. How very two dimensional! > However, if the vCard spec is updated to include an altitude >component, then it will definately become a part of the hCard spec too. >http://microformats.org/wiki/hcard-issues I have yet to see any good reason why hCard (and Geo) cannot have extra fields, which are simply dropped when generating vCards (likewise hCalendar - see the "date of death" debate) >> My second question is whether or not, for line data, it is acceptable >> to include multiple latitude and longitude classes, in sequence, which >> make up the line in sequence or if there is a better way to do it? > >What kind of use do you envisage web tools being able to use that line >sequence information for? Route mapping? Boundary description? >This may be a case where something greater than the Geo microformat >(which is point specific) is required. There is no reason why this could not be an extension of Geo. Note also: -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue Mar 13 14:56:11 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:31 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <1b42308f0703131348ye81ed76l39f8b44fbb520739@mail.gmail.com> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <0BDC6C49-3483-486E-9828-4476E380357B@randomchaos.com> <1b42308f0703131348ye81ed76l39f8b44fbb520739@mail.gmail.com> Message-ID: In message <1b42308f0703131348ye81ed76l39f8b44fbb520739@mail.gmail.com>, Jon Clausen writes >> >I can certainly submit a proposal for >> > the route format >> >> Please follow the process: >> >> http://microformats.org/wiki/process > >Will do. Thanks for your help. Please be aware of: (extends geo for representing coordinates on other planets, moons etc.) in order that routes on other bodies (e.g. the path driven by Martian landers) can be included. Thank you - it would be unwise to "fork" Geo by extending it in two different directions, without consolidating those extensions. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Thu Mar 15 11:52:40 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Mar 19 06:07:32 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> Message-ID: In message , Alexander Graf writes >>
>>
>> Latitude: -83.0000 >> Longitude: 43.0000 >> Elevation: 2012.0000 >>
>> etc.... >>
>as geo is just used for encapsulating Lat/Lon values in hCards, I >don't think reusing is a good idea. I don't see how the above would break any existing (or future spec-abiding) "geo" or "hCard" implementations; the elevation data and geo-route class would simply be discarded. >It will change according to the vCard standard. It seems very unlikely that vcard will change at all; it could well be, that if and when it finally does, it needs to follow any future hCard developments, because the alter may well have a greater number of implementations and published examples. -- Andy Mabbett Welcome to the world's longest week! From alexander.graf at deri.org Mon Mar 19 06:18:22 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Mon Mar 19 06:18:30 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> Message-ID: <9A7BB00C-A13F-415D-9038-79C732D9B770@deri.org> Am 15.03.2007 um 20:52 schrieb Andy Mabbett: > In message , > Alexander Graf writes > >>>
>>>
>>> Latitude: -83.0000 >>> Longitude: 43.0000 >>> Elevation: 2012.0000>> abbr> >>>
>>> etc.... >>>
> >> as geo is just used for encapsulating Lat/Lon values in hCards, I >> don't think reusing is a good idea. > > I don't see how the above would break any existing (or future spec- > abiding) "geo" or "hCard" implementations; the elevation data and > geo-route class would simply be discarded. Fair enough. Someone in this discssion said "geo" was locked as it's a subset of hCard, which is locked too. If geo is extendable that's even better! - Elevation is the main feature that is missing - Elevation could be positive and negative - Timestamps for geo data should be optional but possible - How about coordinate formats / map projection / dates? - alex From jason at sixtwothree.org Mon Mar 19 06:37:15 2007 From: jason at sixtwothree.org (Jason Garber) Date: Mon Mar 19 06:37:20 2007 Subject: [uf-discuss] Ficlets and microformats Message-ID: <45FEA01B.7030008@sixtwothree.org> (Apologies if this made it to the list, but I think my original bounced) I'm happy to announce the recent launch of Ficlets (ficlets.com... fancy that), a social micro-fiction site built by a small five-person team at AOL. I won't belabor you all with the who's, why's, and wherefore's (you can get all that on the site). On to the important part. We made a very conscious effort to microformat the crap out of the site. Stories (individual and lists of) are marked up using hAtom. Author bios are marked up as hCards, and comments on stories are marked up using hReview. The code _should_ be pretty good, but I invite you all to check out the site and provide whatever feedback you might have. Thanks! Jason jason@sixtwothree.org From drernie at opendarwin.org Mon Mar 19 06:53:56 2007 From: drernie at opendarwin.org (Dr. Ernie Prabhakar) Date: Mon Mar 19 06:54:00 2007 Subject: [uf-discuss] OT: Free Andy Mabbet! Message-ID: <4B4CE10D-36A7-47C6-8845-0369BC61D2C1@opendarwin.org> Hi all, With only two weeks left in Lent, I still haven't done enough penance, so I figure I need to up the ante. :-) I didn't see any response to my governance proposal , so let me make a more specific request. I for one fully supported the decision by the list administrators to place Andy under moderation, given his behavior at the time. However, Andy has since done a heroic job of making many useful contributions despite the painful constraints he's been forced to live under; and, as far as I know, he's avoiding commenting in an off-topic manner. Therefore, I believe that the administrators ought to either: a) remove his moderation constraint or b) publicly state why they are not removing it I am all for strong leadership, but I also believe it must be publicly accountable to avoid degenerating into tyranny. Does anyone else agree? Respectfully yours, -- Ernie Prabhakar P.S. Again, I apologize if this is off-topic for this list, but I couldn't find any better place to air my concerns, which is why I think we need a dedicated list for such matters http://microformats.org/wiki/governance-issues If anyone can suggest a better mechanism, please let me know. From davidjanes at blogmatrix.com Mon Mar 19 07:03:12 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Mar 19 07:03:19 2007 Subject: [uf-discuss] OT: Free Andy Mabbet! In-Reply-To: <4B4CE10D-36A7-47C6-8845-0369BC61D2C1@opendarwin.org> References: <4B4CE10D-36A7-47C6-8845-0369BC61D2C1@opendarwin.org> Message-ID: <21e523c20703190803x318dba45w7fee9b41ee23672@mail.gmail.com> I concur. On 3/19/07, Dr. Ernie Prabhakar wrote: > > Therefore, I believe that the administrators ought to either: > > a) remove his moderation constraint > > or > > b) publicly state why they are not removing it > > I am all for strong leadership, but I also believe it must be > publicly accountable to avoid degenerating into tyranny. > > Does anyone else agree? -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From nferrier at tapsellferrier.co.uk Mon Mar 19 07:06:58 2007 From: nferrier at tapsellferrier.co.uk (Nic James Ferrier) Date: Mon Mar 19 07:06:49 2007 Subject: [uf-discuss] OT: Free Andy Mabbet! In-Reply-To: <4B4CE10D-36A7-47C6-8845-0369BC61D2C1@opendarwin.org> (Ernie Prabhakar's message of "Mon\, 19 Mar 2007 07\:53\:56 -0700") References: <4B4CE10D-36A7-47C6-8845-0369BC61D2C1@opendarwin.org> Message-ID: <87ircxe0h9.fsf@tapsellferrier.co.uk> "Dr. Ernie Prabhakar" writes: > Does anyone else agree? I do. -- Nic Ferrier ---------------------------------------------------------- Need a linux/java/python/web hacker? I'm in need of work! ---------------------------------------------------------- http://www.tapsellferrier.co.uk From tantek at cs.stanford.edu Mon Mar 19 07:34:50 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Mar 19 07:34:55 2007 Subject: [admin] moving vote from list to wiki page, closing thread. (was Re: [uf-discuss] OT: Free Andy Mabbet!) In-Reply-To: <87ircxe0h9.fsf@tapsellferrier.co.uk> Message-ID: On 3/19/07 8:06 AM, "Nic James Ferrier" wrote: > "Dr. Ernie Prabhakar" writes: > > Again, I apologize if this is off-topic for this list Ernie, as someone who has made overwhelmingly positive contributions to the microformats community, IMHO the occasional OT post is reasonable. >> Does anyone else agree? > > I do. I've created a wiki page to track opinions on this discussion offlist: http://microformats.org/wiki/mailing-list-unmoderation Please add your input there, and do not follow-up/reply to this thread. Thanks, Tantek From pmw57 at xtra.co.nz Mon Mar 19 11:10:37 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 19 11:10:44 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <45F133AB.80205@xtra.co.nz> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> <45F133AB.80205@xtra.co.nz> Message-ID: <45FEE02D.9060606@xtra.co.nz> Andy Mabbett wrote: > Paul Wilkins writes > Our responsibility is to publish valid, semantically-meaningful markup, > not to pander to the former. > >> As the title is currently for screen readers or to disambiguate the >> date, it should be kept in a human understandable format. >> The Constitution of 4/7/76 > > Then why doesn't that apply to dtstart and dtend, for example? If we intend for a microformat to also understand what's going on, we should disambiguate the title even further. The Constitution of 4/7/76 As long as the quotation is left unchanged, the additional information is provided in a means that clearly disambiguates for the intended audience. >> There is some very useful information from the Manual of Style on the >> formatting of dates and numbers. >> http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28dates_and_numb >> ers%29 >> >> The following is a direct quote of the relevant parts. >> >> >> Incorrect date formats > > [...] > > That's "incorrect" according to the pretences of Wikipedia's > administrators; not by any other authority. There are a number of style guides to pick from. The message I wanted to get across is to try to ensure that it's consistant, for whichever style you pick. That's what the wikipedia group are wanting to achieve and they appear to have a very clear understanding of online writing style. -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From pmw57 at xtra.co.nz Mon Mar 19 11:29:10 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 19 11:29:16 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> References: <011201c7604c$e171a190$bc08a8c0@nzto22> <015f01c76059$66b82b10$bc08a8c0@nzto22> <45F0A1ED.3510.2001717@bjonkman.sobac.com> <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com> Message-ID: <45FEE486.2000300@xtra.co.nz> Andy Mabbett wrote: > In message > <923a87360703090710y113d3ca2taf9e29dc839a4b19@mail.gmail.com>, Ara > Pehlivanian writes > > >>I've always had trouble with the idea of using to mark up dates >>because semantically, it isn't expressing an abbreviation of any sort. > > > That's particularly true of: > > 30 March > > which is an abomination (and an accessibility disaster) which I have > vowed ever to use on web pages under my control. There is a nice way out of this mess though. Provide a time instead of a date and dtend can then end on whatever correct day you desire. 30 March Unfortunately it's not microformats to blame there, as the microformat itself is mirroring to as great an accuracy as possible the already defined behaviour for internet calendaring and scheduling as set out by Apple in RFC 2445. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. When a date only is provided, it's assumed that the time is at midnight. For events that are specified in terms of days, and not time, the end date is the non-inclusive date. If an event goes for one day, saying they start and stop on the same day uses the presumption of a midnight time, so for an event to last for one day, the end *has* to be on the day after. This is why the RFC for internet calendaring and scheduling defines dtend as being a non-inclusive date. The RFC for internet calendaring and scheduling is at http://www.ietf.org/rfc/rfc2445.txt The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE data type but no "DTEND" property, the events non-inclusive end is the end of the calendar date specified by the "DTSTART" property. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME data type but no "DTEND" property, the event ends on the same calendar date and time of day specified by the "DTSTART" property. -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From pmw57 at xtra.co.nz Mon Mar 19 12:11:17 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 19 12:11:20 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <45F5A81A.1010306@xtra.co.nz> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> <009701c76448$af3382c0$bc08a8c0@nzto22> <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> <45F5A81A.1010306@xtra.co.nz> Message-ID: <45FEEE65.9000700@xtra.co.nz> Andy Mabbett wrote: > Can you cite evidence that it's "currently accepted" for non-English > content, as in the above example; or clarify those "sufficient grounds" > for its use in such cases, please? This would be the first defining instance of such a use. If there are other currently accepted methods for providing non-english content with machine readable information, they can be looked in to as well. What methods are out there that provide an english term that means the same as the non-english word or phrase? All Ara wants is for his fax number to be accepted when the fax name is spelled out in French instead of English. What tools do we have to provide an english term for the parser to understand? How do we make the following understandable by the microformat system? T?l: (514) 123-4567 T?l?c: (514) 123-4568 -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From pmw57 at xtra.co.nz Mon Mar 19 12:37:23 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 19 12:37:30 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <8blVPF7HzK9FFwBx@pigsonthewing.org.uk> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <8blVPF7HzK9FFwBx@pigsonthewing.org.uk> Message-ID: <45FEF483.7080602@xtra.co.nz> Andy Mabbett wrote: > Ara Pehlivanian writes >> >>Voice T?l.: (514) 123-4567 >>Fax T?l?c.: (514) 123-4568 > > > T?l > > T?l?c > > Though there are concerns that that's an abuse of "abbr". There is a possible alternative, inspired from http://microformats.org/wiki/hcard-faq#How_do_you_create_non_English_tooltips Fax: If abbr is considered to be too semantically incorrect, it's the only other currently viable method where the native language term is revealed in a tooltip. -- Paul Mark Wilkins New Zealand Tourism Online pmw57@xtra.co.nz 109 Tuam Street Level 1 Christchurch 8011 New Zealand +64 3 963 5039 From paul_wilkins at xtra.co.nz Mon Mar 19 14:57:53 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Mon Mar 19 14:57:57 2007 Subject: [uf-discuss] An Inconvenient hCard References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com><8blVPF7HzK9FFwBx@pigsonthewing.org.uk> <45FEF483.7080602@xtra.co.nz> Message-ID: <004e01c76a7a$07143e30$bc08a8c0@nzto22> From: "Paul Wilkins" > Andy Mabbett wrote: >> Ara Pehlivanian writes >>> >>>Voice T?l.: (514) 123-4567 >>>Fax T?l?c.: (514) 123-4568 >> >> T?l >> >> T?l?c >> >> Though there are concerns that that's an abuse of "abbr". > > There is a possible alternative, inspired from > http://microformats.org/wiki/hcard-faq#How_do_you_create_non_English_tooltips > > Fax: Additionally, there is an existing example of ABBR used for telephones 3.3.1 TEL Type Definition at http://microformats.org/wiki/hcard-examples#3.3.1_TEL_Type_Definition my work phone, with voicemail: +1-213-555-1234 This is an existing microformat example where abbr is used to provide machine understandable terms for human readable content. How great is the difference between that and these examples phone tel T?l T?l?c I say that because of the abbr use in TEL Type Definition, it is acceptable use to use abbr to provide microformat terms for non-understandable content. -- Paul Wilkins From mdagn at spraci.com Mon Mar 19 18:12:36 2007 From: mdagn at spraci.com (Michael MD) Date: Mon Mar 19 18:10:26 2007 Subject: [uf-discuss] Geo Elevation Data References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com><004001c76527$85ca0e10$bc08a8c0@nzto22><1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> Message-ID: <002301c76a95$3dad2fe0$116bacca@COMCEN> >>> Elevation: 2012.0000 I assume this is in the international metric standard of metres? (some Americans might try to mark it up in feet which would really confuse things...) From ryan at technorati.com Mon Mar 19 21:56:54 2007 From: ryan at technorati.com (Ryan King) Date: Mon Mar 19 21:56:58 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> Message-ID: <1D26C260-F04F-4A6F-8C31-6DA7444D6B0D@technorati.com> On Mar 11, 2007, at 6:06 PM, Ara Pehlivanian wrote: > I've got a bit of a problem with an hCard that I need to mark up and I > was wondering if anyone could lend me a hand. > > I realize the syntax requires that a type be specified for telephone > numbers ("voice", "fax", etc...) and that's where my problem lies. Type is not required. -ryan -- Ryan King ryan@technorati.com From alexander.graf at deri.org Tue Mar 20 01:11:01 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Tue Mar 20 01:11:11 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <002301c76a95$3dad2fe0$116bacca@COMCEN> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com><004001c76527$85ca0e10$bc08a8c0@nzto22><1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> Message-ID: On 20.03.2007, at 03:12, Michael MD wrote: >>>> Elevation: 2012.0000>>> abbr> > > I assume this is in the international metric standard of metres? > > (some Americans might try to mark it up in feet which would really > confuse things...) I think we should either use meters or allow for an additional parameter which specifies the metric standard. From brian.suda at gmail.com Tue Mar 20 01:30:28 2007 From: brian.suda at gmail.com (Brian Suda) Date: Tue Mar 20 01:30:30 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> Message-ID: <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> On 3/20/07, Alexander Graf wrote: > I think we should either use meters or allow for an additional > parameter which specifies > the metric standard. --- microformats model Real-World behaviors, so what you THINK is not what gets model. We need to look into how things are ACTUALLY being published. The W3C has an RDF representation of GEO coordinates and even though there is an ALTITUDE component, it is rarely used! Even google Earth defaults the ALTITUDE to the land height at a given lat/lon -brian -- brian suda http://suda.co.uk From paul_wilkins at xtra.co.nz Tue Mar 20 01:34:08 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Tue Mar 20 01:34:14 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <1D26C260-F04F-4A6F-8C31-6DA7444D6B0D@technorati.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <1D26C260-F04F-4A6F-8C31-6DA7444D6B0D@technorati.com> Message-ID: <45FFAA90.8060002@xtra.co.nz> Ryan King wrote: > On Mar 11, 2007, at 6:06 PM, Ara Pehlivanian wrote: > >> I've got a bit of a problem with an hCard that I need to mark up and >> I was wondering if anyone could lend me a hand. > > Type is not required. Thanks for the reality check Ryan. With you knowledge and experience of microformats, do you have some advice for Ara on how to to markup the following example so that the appropriate fax numbers can be given the appropriate type as a fax number? T?l.: (514) 123-4567 T?l?c.: (514) 123-4568 -- Paul Wilkins From costello at mitre.org Tue Mar 20 02:53:14 2007 From: costello at mitre.org (Costello, Roger L.) Date: Tue Mar 20 02:53:17 2007 Subject: [uf-discuss] Making Local Knowledge Globally Useful [was: Zen of Microformats] Message-ID: Hi Folks, A couple weeks back we had an excellent discussion on how Microformats enable information to be both resolutely local and globally useful. I have captured the discussion on a wiki page: http://www.xfront-wiki.com/wiki/index.php?title=Making_Local_Knowlege_G lobally_Useful I invite you to participate in evolving this article. /Roger From danny.ayers at gmail.com Tue Mar 20 03:55:03 2007 From: danny.ayers at gmail.com (Danny Ayers) Date: Tue Mar 20 03:55:09 2007 Subject: [uf-discuss] Microformats survey (for GRDDL) Message-ID: <1f2ed5cd0703200455i1c53173ai1bab60eba2673daa@mail.gmail.com> I've completed a survey of the current state of microformats with regard to the GRDDL mechanism for data extraction. In principle GRDDL is usable on all documents which use microformats. Results tabulated at: http://esw.w3.org/topic/CustomRdfDialects/GrddableMicroformats (It's on the ESW Wiki - please correct any errors/omissions directly) Short version: following a strict interpretation of the relevant specs, no official microformats are currently usable with GRDDL. Taking a loose view, around a third are right now. Summary: As anticipated, the weakest link is the non-existence of profile URIs. Of the 18 microformats listed, only 3 have profile URIs directly usable by GRDDL-aware agents (hCard, hCalendar & hReview), and none of these URIs are endorsed by microformats.org. Only 1 of the 18 has an endorsed profile URI (XFN), and that isn't GRDDL-enabled. It was suggested on microformats-discuss that relevant Wiki pages for the microformats could be used as interim profile URIs, but again these aren't GRDDL-enabled. Most of the microformats do have an XMDP expression of their profile, yet with a couple of exceptions these are listed as source markup, i.e. not really human or machine-readable. It isn't obvious what the intended purpose of this might be. XSLT to RDF/XML is available in various stages of completion for 6 of the 18 microformats listed (including the 3 with unofficial profile URIs). In other words, only 4 of these 18 formats exploit the HTML specification fully for disambiguation. Because the profile URIs corresponding to 3 of these have appeared outside the microformats.org process, only one format+profileURI combination may properly be called a microformat (rather than 'semantic HTML'), and that one isn't GRDDLable. While this limits the publisher's options when it comes to publishing data in HTML, consumers may still use heuristics based on GRDDL or similar mechanisms to extract data from microformat-enhanced documents (i.e. screenscraping), with the obvious impact on reliability & authority of the data, questions of provenance etc. Cheers, Danny. -- http://dannyayers.com From alexander.graf at deri.org Tue Mar 20 03:57:07 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Tue Mar 20 03:57:18 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> Message-ID: <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> On 20.03.2007, at 10:30, Brian Suda wrote: > On 3/20/07, Alexander Graf wrote: >> I think we should either use meters or allow for an additional >> parameter which specifies >> the metric standard. > > --- microformats model Real-World behaviors, so what you THINK is not > what gets model. We need to look into how things are ACTUALLY being > published. > > The W3C has an RDF representation of GEO coordinates and even though > there is an ALTITUDE component, it is rarely used! Even google Earth > defaults the ALTITUDE to the land height at a given lat/lon > > -brian We don't know the land height though. Several people are already publishing waypoints with altitude information, as, for example, here: http://gpsnepal.com/waypoint.php?trek=everest Note how he specifies that the altitude is given in meters? Others publish the altitude in feet. So it's not what I THINK, it's what is ACTUALLY being published. - alex From scott at randomchaos.com Tue Mar 20 05:25:14 2007 From: scott at randomchaos.com (Scott Reynen) Date: Tue Mar 20 05:25:36 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> Message-ID: On Mar 20, 2007, at 6:57 AM, Alexander Graf wrote: > We don't know the land height though. Several people are already > publishing > waypoints with altitude information, as, for example, here: > > http://gpsnepal.com/waypoint.php?trek=everest > > Note how he specifies that the altitude is given in meters? Others > publish the > altitude in feet. So it's not what I THINK, it's what is ACTUALLY > being published. But is it actually being published widely enough to be considered an established standard we can model? We can't determine that from one or two examples. Per the process, please document a wide variety of such examples in the wiki, so we can keep everyone on the same page and avoid wasting our time with speculation about what might be standard publishing behavior. Even if you've personally seen all of these examples, no one else has, and microformats require community consensus. Peace, Scott From alexander.graf at deri.org Tue Mar 20 07:38:41 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Tue Mar 20 07:38:51 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> Message-ID: On 20.03.2007, at 14:25, Scott Reynen wrote: > On Mar 20, 2007, at 6:57 AM, Alexander Graf wrote: > >> We don't know the land height though. Several people are already >> publishing >> waypoints with altitude information, as, for example, here: >> >> http://gpsnepal.com/waypoint.php?trek=everest >> >> Note how he specifies that the altitude is given in meters? Others >> publish the >> altitude in feet. So it's not what I THINK, it's what is ACTUALLY >> being published. > > But is it actually being published widely enough to be considered > an established standard we can model? We can't determine that from > one or two examples. Per the process, please document a wide > variety of such examples in the wiki, so we can keep everyone on > the same page and avoid wasting our time with speculation about > what might be standard publishing behavior. Even if you've > personally seen all of these examples, no one else has, and > microformats require community consensus. http://www.waypoint.org/gps2-list210.html http://gpsnepal.com/waypoint.php?trek=everest (or any other treks) http://www.way-points.nl/waypoints/rubriek.asp?cat=2&type=rubriek http://members.aol.com/gpspage/waypoints.html just as an example... I'm sure I'll find more... - Alex From andy at pigsonthewing.org.uk Tue Mar 20 02:37:44 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Mar 20 08:19:12 2007 Subject: [uf-discuss] Measurement uF (was: Geo Elevation Data) In-Reply-To: References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com><004001c76527$85ca0e10$bc08a8c0@nzto22><1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> Message-ID: <52880.195.70.71.170.1174387064.squirrel@www.gradwell.com> On Tue, March 20, 2007 09:11, Alexander Graf wrote: > On 20.03.2007, at 03:12, Michael MD wrote: > >>>>> Elevation: 2012.0000>>>> abbr> >> >> I assume this is in the international metric standard of metres? >> >> >> (some Americans might try to mark it up in feet which would really >> confuse things...) > > I think we should either use meters or allow for an additional > parameter which specifies the metric standard. Which brings us back to previous discussion of the need for a microformat for marking up "measurements" (perhaps in both SI units and other, specified) types. Such a uF could then be used as a component of any number of other formats. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Tue Mar 20 04:30:18 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Mar 20 08:19:13 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> Message-ID: <39890.195.70.71.170.1174393818.squirrel@www.gradwell.com> On Tue, March 20, 2007 11:57, Alexander Graf wrote: > Several people are already > publishing waypoints with altitude information, as, for example, here: > > http://gpsnepal.com/waypoint.php?trek=everest In addition to need ing an extension to Geo for altitude, that looks like a possible candidate for hAtom, for timing/ sequencing. -- Andy Mabbett Welcome to the world's longest week! From scott at randomchaos.com Tue Mar 20 08:21:04 2007 From: scott at randomchaos.com (Scott Reynen) Date: Tue Mar 20 08:21:23 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> Message-ID: On Mar 20, 2007, at 10:38 AM, Alexander Graf wrote: > On 20.03.2007, at 14:25, Scott Reynen wrote: > >> Per the process, please document a wide variety of such examples >> in the wiki > > http://www.waypoint.org/gps2-list210.html > http://gpsnepal.com/waypoint.php?trek=everest (or any other treks) > http://www.way-points.nl/waypoints/rubriek.asp?cat=2&type=rubriek > http://members.aol.com/gpspage/waypoints.html > > just as an example... I'm sure I'll find more... Good. Now you (or anyone else interested in this) should put those in the wiki where they can be more easily found and analyzed by others. As a demonstration, I started a page for this, based on the examples template: http://microformats.org/wiki/geo-elevation-examples I have no personal experience working with elevation data, so if I've mis-stated the problem you're trying to solve, please correct on that page. Peace, Scott From fberriman at gmail.com Tue Mar 20 09:10:11 2007 From: fberriman at gmail.com (Frances Berriman) Date: Tue Mar 20 09:10:16 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> Message-ID: On 20/03/07, Scott Reynen wrote: > On Mar 20, 2007, at 10:38 AM, Alexander Graf wrote: > > > On 20.03.2007, at 14:25, Scott Reynen wrote: > > > >> Per the process, please document a wide variety of such examples > >> in the wiki > > > > http://www.waypoint.org/gps2-list210.html > > http://gpsnepal.com/waypoint.php?trek=everest (or any other treks) > > http://www.way-points.nl/waypoints/rubriek.asp?cat=2&type=rubriek > > http://members.aol.com/gpspage/waypoints.html > > > > just as an example... I'm sure I'll find more... > > Good. Now you (or anyone else interested in this) should put those > in the wiki where they can be more easily found and analyzed by > others. As a demonstration, I started a page for this, based on the > examples template: > > http://microformats.org/wiki/geo-elevation-examples > > I have no personal experience working with elevation data, so if I've > mis-stated the problem you're trying to solve, please correct on that > page. Can I also mention that this thread would be best suited to the microformats-new mailing list? [1] The idea is to keep creation noise on this list to a minimum. Thank you, [1]http://microformats.org/wiki/mailing-lists#microformats-new -- Frances Berriman http://fberriman.com From andy at pigsonthewing.org.uk Tue Mar 20 12:35:35 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Mar 20 14:27:55 2007 Subject: [uf-discuss] Geo Elevation Data In-Reply-To: References: <1b42308f0703122057h6c25197dg674af511cb043676@mail.gmail.com> <004001c76527$85ca0e10$bc08a8c0@nzto22> <1b42308f0703131028x260ae36w6f5c8859261d4d12@mail.gmail.com> <002301c76a95$3dad2fe0$116bacca@COMCEN> <21e770780703200230g70980579ya4ac8c0a26aeb233@mail.gmail.com> <1E9970C4-1442-47CD-A9E2-4F3B556F341A@deri.org> Message-ID: In message , Scott Reynen writes >But is it actually being published widely enough to be considered an >established standard we can model? We can't determine that from one or >two examples. Per the process, please document a wide variety of such >examples How many is a sufficiently "wide variety"? The 'process' doesn't give any indication. -- Andy Mabbett Welcome to the world's longest week! From paul_wilkins at xtra.co.nz Tue Mar 20 15:55:34 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Tue Mar 20 15:55:41 2007 Subject: [uf-discuss] An Inconvenient hCard References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> Message-ID: <006b01c76b4b$40911e40$bc08a8c0@nzto22> From: "Ara Pehlivanian" To: "Microformats Discuss" Sent: Monday, March 12, 2007 1:06 PM Subject: [uf-discuss] An Inconvenient hCard > I've got a bit of a problem with an hCard that I need to mark up and I > was wondering if anyone could lend me a hand. > > I realize the syntax requires that a type be specified for telephone > numbers ("voice", "fax", etc...) and that's where my problem lies. > It's inconvenient to have the word "voice" appear in the markup > because that's not how the convention (at least in this neck of the > woods) is when writing out contact information. The final display > should be: > > Tel.: (514) 123-4567 > Fax: (514) 123-4568 > > Yet with the required "voice"/"fax" types it ends up like this: > > Voice Tel.: (514) 123-4567 > Fax Fax: (514) 123-4568 > > or in the French version of the page: > > Voice T?l.: (514) 123-4567 > Fax T?l?c.: (514) 123-4568 > > I realize that it's simple enough to just hide the types via CSS, but > being the strict standards advocate that I am, I don't like entangling > the structural layer with the presentational one by making it > dependent on it. The idea of superfluous words littering my markup > without proper grammatical consideration doesn't sit well with me. > > I thought of doing something like this: > > Tel.: (514) 123-4567 (Voice) > Fax: (514) 123-4567 (Fax) > > or in the French: > > T?l.: (514) 123-4567 (Voice) > T?l?c.: (514) 123-4568 (Fax) > > But it's redundant in English and nonsensical in French. > > So, dear Microformats community, please lend me a hand and help me > unravel this conundrum of mine. I have a creative solution here for you, inspired from Fax T?l?c.: (514) 123-4568 If the page is in a foriegn language, such as French, you really should mark up non-French words with the appropriate language attribute HTML - lang XHTML 1.0 - lang and xml:lang XHTML 1.1 - xml:lang FaxT?l?c.: (514) 123-4568 Then you can use a stylesheet to hide the english word. span [lang=en] {display: none;} Let's take this one further. Markup the new code as a telephone microformat.
Fax T?l?c.: (514) 123-4568
And hide the english text inside the microformat .tel [lang=en] {display: none;} -- Paul Wilkins From ara.pehlivanian at gmail.com Tue Mar 20 17:00:45 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Tue Mar 20 17:00:51 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <006b01c76b4b$40911e40$bc08a8c0@nzto22> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <006b01c76b4b$40911e40$bc08a8c0@nzto22> Message-ID: <923a87360703201800x1b28f591t5f3de070e456e78e@mail.gmail.com> On 3/20/07, Paul Wilkins wrote: > From: "Ara Pehlivanian" > To: "Microformats Discuss" > Sent: Monday, March 12, 2007 1:06 PM > Subject: [uf-discuss] An Inconvenient hCard > > > > I've got a bit of a problem with an hCard that I need to mark up and I > > was wondering if anyone could lend me a hand. > > > > I realize the syntax requires that a type be specified for telephone > > numbers ("voice", "fax", etc...) and that's where my problem lies. > > It's inconvenient to have the word "voice" appear in the markup > > because that's not how the convention (at least in this neck of the > > woods) is when writing out contact information. The final display > > should be: > > > > Tel.: (514) 123-4567 > > Fax: (514) 123-4568 > > > > Yet with the required "voice"/"fax" types it ends up like this: > > > > Voice Tel.: (514) 123-4567 > > Fax Fax: (514) 123-4568 > > > > or in the French version of the page: > > > > Voice T?l.: (514) 123-4567 > > Fax T?l?c.: (514) 123-4568 > > > > I realize that it's simple enough to just hide the types via CSS, but > > being the strict standards advocate that I am, I don't like entangling > > the structural layer with the presentational one by making it > > dependent on it. The idea of superfluous words littering my markup > > without proper grammatical consideration doesn't sit well with me. > > > > I thought of doing something like this: > > > > Tel.: (514) 123-4567 (Voice) > > Fax: (514) 123-4567 (Fax) > > > > or in the French: > > > > T?l.: (514) 123-4567 (Voice) > > T?l?c.: (514) 123-4568 (Fax) > > > > But it's redundant in English and nonsensical in French. > > > > So, dear Microformats community, please lend me a hand and help me > > unravel this conundrum of mine. > > I have a creative solution here for you, inspired from > Fax T?l?c.: (514) 123-4568 > > If the page is in a foriegn language, such as French, you really should mark > up non-French words with the appropriate language attribute > HTML - lang > XHTML 1.0 - lang and xml:lang > XHTML 1.1 - xml:lang > FaxT?l?c.: (514) 123-4568 > > Then you can use a stylesheet to hide the english word. > span [lang=en] {display: none;} > > Let's take this one further. Markup the new code as a telephone microformat. > >
> Fax > T?l?c.: > (514) 123-4568 >
> > And hide the english text inside the microformat > .tel [lang=en] {display: none;} > Thanks for the work you put into this solution but I've got two problems with it. The first being what I mentioned in my initial posting (though I may not have been overly clear about it), but hiding content in CSS still means that the content is there for unstyled viewing. Secondly, the attribute selector isn't widely supported enough to make the solution viable on most browsers (in particular IE). Thanks though. :-/ A. -- Ara Pehlivanian Site: http://arapehlivanian.com/ Email & GTalk: ara.pehlivanian@gmail.com MSN: ara_p@hotmail.com Twitter: http://twitter.com/ara_p/ From paul_wilkins at xtra.co.nz Tue Mar 20 17:29:16 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Tue Mar 20 17:29:20 2007 Subject: [uf-discuss] An Inconvenient hCard References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com><006b01c76b4b$40911e40$bc08a8c0@nzto22> <923a87360703201800x1b28f591t5f3de070e456e78e@mail.gmail.com> Message-ID: <008201c76b58$57347c20$bc08a8c0@nzto22> From: "Ara Pehlivanian" > On 3/20/07, Paul Wilkins wrote: >>
>> Fax >> T?l?c.: >> (514) 123-4568 >>
>> >> And hide the english text inside the microformat >> .tel [lang=en] {display: none;} > > Thanks for the work you put into this solution but I've got two > problems with it. The first being what I mentioned in my initial > posting (though I may not have been overly clear about it), but hiding > content in CSS still means that the content is there for unstyled > viewing. Secondly, the attribute selector isn't widely supported > enough to make the solution viable on most browsers (in particular > IE). > > Thanks though. :-/ That's all right Ara. Until IE6 becomes less of an impact, there are two other options. One makes use of a slight loosening of the semantics of the abbr element.
T?l?c.: (514) 123-4568
And the other discards any ability to separate the phone number by its appropriate type, but is at least guaranteed to work in a minimal nature.
T?l.: (514) 123-4567 T?l?c.: (514) 123-4568 -ryan -- Ryan King ryan@technorati.com From ara.pehlivanian at gmail.com Wed Mar 21 09:18:18 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Wed Mar 21 09:18:27 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <1D26C260-F04F-4A6F-8C31-6DA7444D6B0D@technorati.com> <45FFAA90.8060002@xtra.co.nz> <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com> Message-ID: <923a87360703211018m1a3a7287uec0bcb688a454c30@mail.gmail.com> On 3/21/07, Ryan King wrote: > On Mar 20, 2007, at 2:34 AM, Paul Wilkins wrote: > > > Ryan King wrote: > > > On Mar 11, 2007, at 6:06 PM, Ara Pehlivanian wrote: > > > > > >> I've got a bit of a problem with an hCard that I need to mark up > > and > > >> I was wondering if anyone could lend me a hand. > > > > > > Type is not required. > > > > Thanks for the reality check Ryan. > > > > With you knowledge and experience of microformats, do you have some > > advice for Ara on how to to markup the following example so that > > the appropriate fax numbers can be given the appropriate type as a > > fax number? > > > > T?l.: (514) 123-4567 > > T?l?c.: (514) 123-4568 > > Assuming 'T?l?c' means something like 'fax', I'd do it like this: > > > T?l.: (514) 123-4567 > T?l?c.: class="value">(514) 123-4568 Does the following make any sense to you as a potential solution to i18n? T?l?phone: (514) 123-4567 T?l?copieur: (514) 123-4568 as opposed to stretching the semantics of the tag? A. -- Ara Pehlivanian Site: http://arapehlivanian.com/ Email & GTalk: ara.pehlivanian@gmail.com MSN: ara_p@hotmail.com Twitter: http://twitter.com/ara_p/ From paul_wilkins at xtra.co.nz Wed Mar 21 12:23:47 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Wed Mar 21 12:23:51 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <923a87360703211018m1a3a7287uec0bcb688a454c30@mail.gmail.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <1D26C260-F04F-4A6F-8C31-6DA7444D6B0D@technorati.com> <45FFAA90.8060002@xtra.co.nz> <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com> <923a87360703211018m1a3a7287uec0bcb688a454c30@mail.gmail.com> Message-ID: <46019453.5090201@xtra.co.nz> Ara Pehlivanian wrote: > On 3/21/07, Ryan King wrote: >> T?l.: (514) 123-4567 >> T?l?c.: > class="value">(514) 123-4568 > > > Does the following make any sense to you as a potential solution to i18n? > > T?l?phone: (514) > 123-4567 > T?l?copieur: (514) > 123-4568 > > as opposed to stretching the semantics of the tag? Quoted from http://microformats.org/wiki/hcard-issues REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr was attempted (http://microformats.org/wiki/hcard-parsing#ISSUE_2), and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the visible markup. Note that you can use abbreviations, e.g. W: in order to present the type in a way that may better fit in with the rest of your presentation. -- Paul Wilkins From ara.pehlivanian at gmail.com Wed Mar 21 12:45:08 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Wed Mar 21 12:45:13 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <46019453.5090201@xtra.co.nz> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <1D26C260-F04F-4A6F-8C31-6DA7444D6B0D@technorati.com> <45FFAA90.8060002@xtra.co.nz> <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com> <923a87360703211018m1a3a7287uec0bcb688a454c30@mail.gmail.com> <46019453.5090201@xtra.co.nz> Message-ID: <923a87360703211345ue62e180h316b5ec7fdf2f3bc@mail.gmail.com> On 3/21/07, Paul Wilkins wrote: > Ara Pehlivanian wrote: > > On 3/21/07, Ryan King wrote: > >> T?l.: (514) 123-4567 > >> T?l?c.: >> class="value">(514) 123-4568 > > > > > > Does the following make any sense to you as a potential solution to i18n? > > > > T?l?phone: (514) > > 123-4567 > > T?l?copieur: (514) > > 123-4568 > > > > as opposed to stretching the semantics of the tag? > > Quoted from http://microformats.org/wiki/hcard-issues > > REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr > was attempted (http://microformats.org/wiki/hcard-parsing#ISSUE_2), and > failed in many situations. In addition, the "type" information is actual > data, not just a property name, and thus deserves to be in the visible > markup. Note that you can use abbreviations, e.g. title="work">W: in order to present the type in a way that may > better fit in with the rest of your presentation. Well then, case closed. tag it is! A. -- Ara Pehlivanian Site: http://arapehlivanian.com/ Email & GTalk: ara.pehlivanian@gmail.com MSN: ara_p@hotmail.com Twitter: http://twitter.com/ara_p/ From tjameswhite at yahoo.com Wed Mar 21 13:02:28 2007 From: tjameswhite at yahoo.com (Tim White) Date: Wed Mar 21 13:02:30 2007 Subject: [uf-discuss] An Inconvenient hCard Message-ID: <198863.87519.qm@web30809.mail.mud.yahoo.com> >> T?l.: (514) >123-4567 >> T?l?c.: >> class="value">(514) 123-4568 > >Does the following make any sense to you as a potential solution to >i18n? [clip] >as opposed to stretching the semantics of the tag? This doesn't look like a stretch of , Telec. is an abbreviation of T?l?copieur, which is "fax" in English (and I believe it has already been established that properties are in English.) Would it be legal to write Telec. Thus satisfying the title for parsers and title for users? ~ Tim tjameswhite.com'>http://www.tjameswhite.com">tjameswhite.com ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ From andy at pigsonthewing.org.uk Wed Mar 21 02:27:14 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 21 20:15:56 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <008201c76b58$57347c20$bc08a8c0@nzto22> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <006b01c76b4b$40911e40$bc08a8c0@nzto22> <923a87360703201800x1b28f591t5f3de070e456e78e@mail.gmail.com> <008201c76b58$57347c20$bc08a8c0@nzto22> Message-ID: <0cpnOiOCiQAGFwkj@pigsonthewing.org.uk> In message <008201c76b58$57347c20$bc08a8c0@nzto22>, Paul Wilkins writes >a slight loosening of the semantics of the abbr element. >
T?l?c.: > (514) 123-4568 >
This thread is going in circles, On 12 March, I wrote, having suggested the same possibility, that: ...there are concerns that that's an abuse of "abbr". -- Andy Mabbett Welcome to the world's longest week! From paul_wilkins at xtra.co.nz Wed Mar 21 20:33:31 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Wed Mar 21 20:33:39 2007 Subject: [uf-discuss] An Inconvenient hCard References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com><006b01c76b4b$40911e40$bc08a8c0@nzto22><923a87360703201800x1b28f591t5f3de070e456e78e@mail.gmail.com><008201c76b58$57347c20$bc08a8c0@nzto22> <0cpnOiOCiQAGFwkj@pigsonthewing.org.uk> Message-ID: <008801c76c3b$3f0941b0$bc08a8c0@nzto22> From: "Andy Mabbett" > In message <008201c76b58$57347c20$bc08a8c0@nzto22>, Paul Wilkins > writes > >>a slight loosening of the semantics of the abbr element. >>
T?l?c.: >> (514) 123-4568 >>
> > This thread is going in circles, On 12 March, I wrote, having suggested > the same possibility, that: > > ...there are concerns that that's an abuse of "abbr". I think that abuse is too strong a term for what's happening here. There is historical evidence that in the case of microformats, such a thing is allowed. To markup the following vcard example. http://microformats.org/wiki/hcard-examples#3.3.1_TEL_Type_Definition TEL;TYPE=work,voice,pref,msg:+1-213-555-1234 my work phone, with voicemail: +1-213-555-1234 -- Paul Wilkins From andy at pigsonthewing.org.uk Thu Mar 22 03:27:05 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Mar 22 07:12:57 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <008801c76c3b$3f0941b0$bc08a8c0@nzto22> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <006b01c76b4b$40911e40$bc08a8c0@nzto22> <923a87360703201800x1b28f591t5f3de070e456e78e@mail.gmail.com> <008201c76b58$57347c20$bc08a8c0@nzto22> <0cpnOiOCiQAGFwkj@pigsonthewing.org.uk> <008801c76c3b$3f0941b0$bc08a8c0@nzto22> Message-ID: In message <008801c76c3b$3f0941b0$bc08a8c0@nzto22>, Paul Wilkins writes >>> T?l?c.: >>> (514) 123-4568 >> This thread is going in circles, On 12 March, I wrote, having suggested >> the same possibility, that: >> >> ...there are concerns that that's an abuse of "abbr". > >I think that abuse is too strong a term for what's happening here. > >There is historical evidence that in the case of microformats, such a >thing is allowed. 1) Please cite "historical evidence" of *different-language* abbr content and titles being used. 2) That an HTML element is being used in a particular way "in the case of microformats" does not mean that it is not an abuse of what was originally intended by the relevant HTML standard. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Thu Mar 22 03:29:11 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Mar 22 07:12:59 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <198863.87519.qm@web30809.mail.mud.yahoo.com> References: <198863.87519.qm@web30809.mail.mud.yahoo.com> Message-ID: In message <198863.87519.qm@web30809.mail.mud.yahoo.com>, Tim White writes >Would it be legal to write >Telec. Thus >satisfying the title for parsers and title for users? Legal in HTML? Yes. Semantically meaningful? No. Helpful to the user? No. Valid in hCard? No. -- Andy Mabbett Welcome to the world's longest week! From chris.messina at gmail.com Thu Mar 22 10:41:17 2007 From: chris.messina at gmail.com (Chris Messina) Date: Thu Mar 22 10:41:20 2007 Subject: [uf-discuss] Hatom or hcalendar? Message-ID: <1bc4603e0703221141x4748b03bnefd86b41f2e707de@mail.gmail.com> Hey all, Question: would you mark up Twitter statuses with hatom or hcalendar? The reason I ask is that Jeremy Keith's lifestream uses hcalendar -- and that statuses have either a title or content, but not both -- whereas the status itself could be consider the hcalendar summary... Of course the answer would also be useful for tumblelogs... Thoughts? Chris -- Chris Messina Citizen Provocateur & Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private From chris.messina at gmail.com Thu Mar 22 12:39:59 2007 From: chris.messina at gmail.com (Chris Messina) Date: Thu Mar 22 12:40:06 2007 Subject: [uf-discuss] Ficlets and microformats In-Reply-To: <45FEA01B.7030008@sixtwothree.org> References: <45FEA01B.7030008@sixtwothree.org> Message-ID: <1bc4603e0703221339m581bd4b5g3a9d4ee0d6155a10@mail.gmail.com> BTW Jason, great work! The site looks awesome -- and I'm thrilled by your use of microformats and OpenID. If anything, just wanted to give you proper props! Chris On 3/19/07, Jason Garber wrote: > (Apologies if this made it to the list, but I think my original bounced) > > I'm happy to announce the recent launch of Ficlets (ficlets.com... fancy > that), a social micro-fiction site built by a small five-person team at > AOL. I won't belabor you all with the who's, why's, and wherefore's (you > can get all that on the site). On to the important part. > > We made a very conscious effort to microformat the crap out of the site. > Stories (individual and lists of) are marked up using hAtom. Author bios > are marked up as hCards, and comments on stories are marked up using > hReview. > > The code _should_ be pretty good, but I invite you all to check out the > site and provide whatever feedback you might have. > > Thanks! > > Jason > jason@sixtwothree.org > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Chris Messina Citizen Provocateur & Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private From hsivonen at iki.fi Thu Mar 22 13:08:54 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu Mar 22 13:09:00 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator In-Reply-To: <45F31ED3.90500@xtra.co.nz> References: <45F31ED3.90500@xtra.co.nz> Message-ID: <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> (Sorry about my frustrated tone. I always get frustrated when I try to extract implementation directions from the wiki and fail. This isn't the first time. And I can read specs in general.) On Mar 10, 2007, at 23:10, Paul Wilkins wrote: > Henri Sivonen wrote: > >> I needed a .bib-based bibliography generator for XHTML, so I >> wrote one with help from a friend who had developed a .bib >> parser. The output of my generator can be seen at >> http://hsivonen.iki.fi/thesis/html5-conformance- >> checker.xhtml#references >> >> I've wrapped the values of .bib fields in elements whose class >> name is the .bib field name. I did it just in case. I don't have >> any consumer use case for those class names. It was just super- >> easy to generate them. >> >> My use case (publishing an academic paper with a bibliography) is >> not mentioned as a use case at >> http://microformats.org/wiki/citation-brainstorming . More to the >> point, the wiki has no consumer use case for my publication use case. >> >> Does this mean that hCite is not for me at all? > > Not at all. You are using the BibTex format, which is covered in > the citation formats http://microformats.org/wiki/citation-formats Sure, but considering that I share my .bib, should I expect people to want to scrape my (X)HTML-formatted bibliography? >> If hCite is for me, what's the elevator pitch convincing me to >> put more effort into my generator? What benefits should I expect >> if I do? Is hCite mature enough to be implemented yet? > > The citation microformat is a work in progress at this stage, so > it's not mature enough for programs to extract information from it, I guess this means that I shouldn't try to support hCite on the generator side in my thesis considering that the document should go final on the first week of April. Would it be of any use to anyone if I wrapped the name of each author/ editor in a if I otherwise leave my markup the way it is now? > The benefits are that people visitng your content with next > generation tools wil be able to easily extract and use the > information in more interesting and useful ways. So basically, my effort would not be about catering to specific realistic foreseeable use cases. Instead, it would be about putting data out there in case someone figures out a use case later on. > Tantek has a recent presentation about the big picture of > microformats at http://tantek.com/presentations/2007/02/microformats/ I think I know the base theory. I am interested in practical use cases and implementability in this particular case. >> Moreover, is it even possible to generate hCite from my source >> data (http://hsivonen.iki.fi/thesis/dippa.bib) without >> sacrificing the presentation that I want and without potentially >> generating bogus markup for personal names? > > One of the big ideas behind the use of microformats is that it will > allow you to markup the content on your page without modifying the > presentation of it. Somehow, I was under the impression that hCite required bibliography items as
s instead of
/
pairs (which is what I use and what W3C and WHATWG specs use). >> For example, my source data does not encode explicitly the given >> name, the family name and other stuff that isn't quite neither. >> As far as I can tell, it is impossible to tell heuristically that >> the middle token in these two names is semantically different: >> Gavin Thomas Nicol >> Henrik Frystyk Nielsen > > Those issues haven't yet been covered for for the citation > microformat. What I'm trying to say is that I think hCite should allow names to be marked up as formatted names tossing the deformatting problem to the consumer. After all, one of the most popular bibliography data format, BibTeX, stores formatted names. > It may be possible for for a generator to parse through them and > extract the appropriate information though. > For example, honorific-prefix and honorific-suffix are a rather > short list. Then after those, the given name, family name and > additional name could be extracted in that particular order. Using heuristics in the generator to make explicit metadata statements is generally a bad idea. If the result is wrong, it still pretends to be authoritative. If heuristics are involved, the input to the heuristic should be sent and consumers should be able to compete on how good their heuristics are. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From scott at randomchaos.com Thu Mar 22 13:26:21 2007 From: scott at randomchaos.com (Scott Reynen) Date: Thu Mar 22 13:26:48 2007 Subject: [uf-discuss] Re: hCard for non-contact-able locations (Was: Disambiguation Conventions?) In-Reply-To: <005701c71e23$b9ae6050$0201a8c0@andrieuhome> References: <005701c71e23$b9ae6050$0201a8c0@andrieuhome> Message-ID: On Dec 12, 2006, at 1:28 PM, Joe Andrieu wrote: > For example, since it was initially stabilized hCard has been > changed to > include "place" in its semantics, yet we have no way to let parsers > know > that the "new" hCards may not be people, companies, or organizations, > but instead may also be places. vCards were for /contactable/ > entities. I was just reading the vCalendar (not vCard) spec [1], and was reminded of the above when I read this: > For example, the alternate representation may specify either an > LDAP URI pointing to an LDAP server entry or a CID URI pointing to > a MIME body part containing a vCard [RFC 2426] for the location. I'm not familiar with the history of the vCard and vCalendar RFCs, but I see that Frank Dawson was an author of both, so it looks like he actually did intend vCards to work for non-contact-able locations (e.g. the example of "conference room"). That doesn't change people's expectations for hCard, but I thought it was interesting that this expansion of hCard mirrored vCard without even realizing it. [1] http://www.ietf.org/rfc/rfc2445.txt Peace, Scott From drernie at opendarwin.org Thu Mar 22 13:37:26 2007 From: drernie at opendarwin.org (Dr. Ernie Prabhakar) Date: Thu Mar 22 13:37:29 2007 Subject: [uf-discuss] OT: Governance (WAS: Free Andy Mabbett!) [with two 't's] In-Reply-To: <4B4CE10D-36A7-47C6-8845-0369BC61D2C1@opendarwin.org> References: <4B4CE10D-36A7-47C6-8845-0369BC61D2C1@opendarwin.org> Message-ID: Hi all, On Mar 19, 2007, at 7:53 AM, Dr. Ernie Prabhakar wrote: > Therefore, I believe that the administrators ought to either: > a) remove his moderation constraint > or > b) publicly state why they are not removing it > http://microformats.org/wiki/governance-issues On Mon Mar 19 07:34:50 PST 2007, Tantek ?elik wrote: > I've created a wiki page to track opinions on this discussion offlist: > > http://microformats.org/wiki/mailing-list-unmoderation > > Please add your input there, and do not follow-up/reply to this > thread. I appreciate Tantek's indulgence for my off-topic post, and his prompt response. However, despite the overwhelmingly positive vote, Andy's moderation does not appear to have been removed, nor has any explanation been given. Again, I fully believe in the good intentions of the leadership, and respect the busyness of their schedules. However, independent of their position on Andy, I feel they owe *the community* a little more respect for our expressed opinion. Then again, maybe that's just me. Let me know (one way or the other) at: http://microformats.org/wiki/governance-issues#Petition In deference to Tantek's wishes, please follow up there (on the wiki) rather than here (on email). Sorry for the interruption. We now return you to your regularly scheduled hCard. Penitently yours, -- Ernie P. From andy at pigsonthewing.org.uk Thu Mar 22 08:10:16 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Mar 22 14:09:10 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <1D26C260-F04F-4A6F-8C31-6DA7444D6B0D@technorati.com> <45FFAA90.8060002@xtra.co.nz> <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com> Message-ID: In message <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com>, Ryan King writes >Assuming 'T?l?c' means something like 'fax', I'd do it like this: I've started a wiki page on issues around internationalisation: -- Andy Mabbett Welcome to the world's longest week! From chris at placenamehere.com Thu Mar 22 14:50:49 2007 From: chris at placenamehere.com (Chris Casciano) Date: Thu Mar 22 14:51:06 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <1D26C260-F04F-4A6F-8C31-6DA7444D6B0D@technorati.com> <45FFAA90.8060002@xtra.co.nz> <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com> Message-ID: On Mar 22, 2007, at 12:10 PM, Andy Mabbett wrote: > In message <24CDA1E5-D10B-4A34-866C-8437620E25AF@technorati.com>, Ryan > King writes > >> Assuming 'T?l?c' means something like 'fax', I'd do it like this: > > I've started a wiki page on issues around internationalisation: > > > you spelled it wrong Andy... its spelled with a "z" ;) -- [ Chris Casciano ] [ chris@placenamehere.com ] [ http://placenamehere.com ] From joe at andrieu.net Thu Mar 22 15:46:50 2007 From: joe at andrieu.net (Joe Andrieu) Date: Thu Mar 22 15:46:50 2007 Subject: [uf-discuss] Re: hCard for non-contact-able locations (Was:Disambiguation Conventions?) In-Reply-To: Message-ID: <003301c76cdc$5d7ff3e0$0201a8c0@andrieuhome> Scott Reynen, March 22, 2007 2:26 PM wrote: > On Dec 12, 2006, at 1:28 PM, Joe Andrieu wrote: > > > For example, since it was initially stabilized hCard has been > > changed to > > include "place" in its semantics, yet we have no way to let > parsers > > know > > that the "new" hCards may not be people, companies, or > organizations, > > but instead may also be places. vCards were for /contactable/ > > entities. > > I was just reading the vCalendar (not vCard) spec [1], and was > reminded of the above when I read this: > > > For example, the alternate representation may specify either an > > LDAP URI pointing to an LDAP server entry or a CID URI pointing to > > a MIME body part containing a vCard [RFC 2426] for the location. > > I'm not familiar with the history of the vCard and vCalendar RFCs, > but I see that Frank Dawson was an author of both, so it looks like > he actually did intend vCards to work for non-contact-able locations > (e.g. the example of "conference room"). That doesn't change > people's expectations for hCard, but I thought it was interesting > that this expansion of hCard mirrored vCard without even realizing it. > > [1] http://www.ietf.org/rfc/rfc2445.txt Scott, Excellent discovery. Given how thorough the rest of the specs are, it is surprising that this alignment isn't present elsewhere. At one point, I had traced the hCard through its entire heritage, never really getting a clear specification. [2] I'd be curious to see if there were any conversations in the standardization process that kept location out of RFC2426. However, given Frank Dawson is lead author on both vCalendar and vCard, location definitely seems to be part of his conceptualzation for what a vCard could be used for. The larger issue, I think, is one of governance. That is, what is the process to approve or revise a microformat? It is all pretty ad-hoc at the moment, leading to seamingly arbitrary assertions, including for example, GEO is locked because hCard is locked. When did hCard get locked? Was that before or after we added "place" as a meaning for it? I don't recall a community discussion about locking anything. If hCard 1.0 is locked, ok. I actually think that's totally appropriate. Then, what's the process for hCard 1.1 or 2.0? Or more pertinant to recent conversations what is the process for Geo 2.0? Although hCard 1.0 locks Geo, it seems reasonable for a Geo 2.0 to be considered. Does anyone else think it would be useful to establish processes around these sorts of decisions? Or do people think that wiki edits monitored by admins is the best solution? [2] http://microformats.org/discuss/mail/microformats-discuss/2006-December/007730.html -j -- Joe Andrieu joe@andrieu.net +1 (805) 705-8651 "An inconvenience is an adventure wrongly considered. An adventure is only an inconvenience rightly considered." --G. K. Chesterton From jeremy at adactio.com Fri Mar 23 04:09:38 2007 From: jeremy at adactio.com (Jeremy Keith) Date: Fri Mar 23 04:09:40 2007 Subject: [uf-discuss] Hatom or hcalendar? In-Reply-To: <1bc4603e0703221141x4748b03bnefd86b41f2e707de@mail.gmail.com> References: <1bc4603e0703221141x4748b03bnefd86b41f2e707de@mail.gmail.com> Message-ID: Chris asked: > Question: would you mark up Twitter statuses with hatom or hcalendar? > > The reason I ask is that Jeremy Keith's lifestream uses hcalendar -- > and that statuses have either a title or content, but not both -- > whereas the status itself could be consider the hcalendar summary... This is a really good question. My first thought was "Yeah, why *didn't* I use hAtom?" After all, there's nothing to stop me using both hCalendar and hAtom... So I started editing the template and I hit a snag: I don't have an author listed for each entry. Author is required for hAtom. Now, I could just put a single hCard somewhere within the hAtom feed and that would solve the problem: From http://microformats.org/wiki/hatom: "If the Entry Author is missing, find the Nearest In Parent
element(s) with class name author and that is/are a valid hCard" But I'm not publishing an
already and isn't the whole idea of microformats that we don't change *what* we're publishing, just add more meaning to what we're already publishing? Of course, I can go ahead and add the hAtom classes anyway: http://lifestream.adactio.com/ But that's not a valid hAtom feed. I have to say that I find it a little weird that author is required but entry-title is not. Looking at the Atom spec, "title" is a required feed element and "author" is recommended. For hAtom, that's been inverted: http://atomenabled.org/developers/syndication/#requiredFeedElements This has probably been discussed before, right? If anybody has some URLs pointing to previous discussions of this issue, that'd be much appreciated. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From paul_wilkins at xtra.co.nz Fri Mar 23 04:22:40 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Fri Mar 23 04:22:45 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator In-Reply-To: <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> Message-ID: <4603C690.5010305@xtra.co.nz> Henri Sivonen wrote: > On Mar 10, 2007, at 23:10, Paul Wilkins wrote: >> You are using the BibTex format, which is covered in the >> citation formats http://microformats.org/wiki/citation-formats > > Sure, but considering that I share my .bib, should I expect people to > want to scrape my (X)HTML-formatted bibliography? If the .bib is used as the lone source for the XHTML, I suspect it would be easier to scrape the .bib file. >> The citation microformat is a work in progress at this stage, so it's >> not mature enough for programs to extract information from it, > > I guess this means that I shouldn't try to support hCite on the > generator side in my thesis considering that the document should go > final on the first week of April. Even though it goes final then, does that prevent you from later on adding markup which doesn't affect the text, yet makes it easier for tools to scrape through the information? > Would it be of any use to anyone if I wrapped the name of each author/ > editor in a if I otherwise leave my markup the way it > is now? A formatted name is quite a restricted format, and if the formatted name doesn't follow a certain prescribed format, it is considered to be invalid and isn't used. Currently the BibTeX is as follows @Misc{AXML, editor = {Tim Bray and Jean Paoli and C.M. Sperberg-McQueen}, title = {The Annotated XML 1.0 Specification}, year = {1998}, publisher = {O'Reilly Media, Inc.}, refdate = {2007-03-04}, url = {http://www.xml.com/pub/a/axml/axmlintro.html} } From which you are wanting to create the following kind of data. [AXML] The Annotated XML 1.0 Specification. Tim Bray, Jean Paoli and C.M. Sperberg-McQueen, editors. O?Reilly Media, Inc., 1998. http://www.xml.com/pub/a/axml/axmlintro.html (referenced: 2007-03-04) The editor section alone will be interesting to markup, because the citation will have to allow multiple editors, in which case both the BibTeX and the microformat will have to be created from a parent source, so that the microformat can gain the name-based information in the format required, while still allowing that information through to become the BibTeX file. >> The benefits are that people visitng your content with next >> generation tools wil be able to easily extract and use the >> information in more interesting and useful ways. > > So basically, my effort would not be about catering to specific > realistic foreseeable use cases. Instead, it would be about putting > data out there in case someone figures out a use case later on. It may be more useful to provide the ISBN number for the book. Then the problems left to be solved become smaller and easier to handle. > Somehow, I was under the impression that hCite required bibliography > items as
s instead of
/
pairs (which is what I use and what > W3C and WHATWG specs use). I'm sure that design patterns can be created to accommodate such a scheme. > What I'm trying to say is that I think hCite should allow names to be > marked up as formatted names tossing the deformatting problem to the > consumer. After all, one of the most popular bibliography data format, > BibTeX, stores formatted names. Currently the formatted names are accepted in the following formats given-name (space) family-name family-name (comma) given-name family-name (comma) given-name-first-initial family-name (space) given-name-first-initial (optional period) How much granularity does BibTeX allow for when storing the formated names for Editors? -- Paul Wilkins From davidjanes at blogmatrix.com Fri Mar 23 04:24:45 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Mar 23 04:25:18 2007 Subject: [uf-discuss] Hatom or hcalendar? In-Reply-To: References: <1bc4603e0703221141x4748b03bnefd86b41f2e707de@mail.gmail.com> Message-ID: <21e523c20703230524x6a1663ddi29d278496bc11ed9@mail.gmail.com> On 3/23/07, Jeremy Keith wrote: > This is a really good question. My first thought was "Yeah, why > *didn't* I use hAtom?" After all, there's nothing to stop me using > both hCalendar and hAtom... > > So I started editing the template and I hit a snag: I don't have an > author listed for each entry. Author is required for hAtom. Now, I > could just put a single hCard somewhere within the hAtom feed and > that would solve the problem: > > From http://microformats.org/wiki/hatom: > "If the Entry Author is missing, find the Nearest In Parent
> element(s) with class name author and that is/are a valid hCard" > > But I'm not publishing an
already and isn't the whole idea > of microformats that we don't change *what* we're publishing, just > add more meaning to what we're already publishing? > > Of course, I can go ahead and add the hAtom classes anyway: > http://lifestream.adactio.com/ > > But that's not a valid hAtom feed. My belief now is that hAtom 0.2 should provide a better set of defaulting rules, especially for "author". It's crazy that hAtom brings you 95% of the way to marking up microcontent and then lets down what seems to be a fairly common use case. What this default should be is a mystery, perhaps something like "page" or "anonymous" with the "url" to be that of the page. > I have to say that I find it a little weird that author is required > but entry-title is not. Looking at the Atom spec, "title" is a > required feed element and "author" is recommended. For hAtom, that's > been inverted: > > http://atomenabled.org/developers/syndication/#requiredFeedElements No, this [1] is what you want to be looking at. Regards, etc... David [1] http://atomenabled.org/developers/syndication/#recommendedEntryElements -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From chris at placenamehere.com Fri Mar 23 04:41:40 2007 From: chris at placenamehere.com (Chris Casciano) Date: Fri Mar 23 04:42:01 2007 Subject: [uf-discuss] Hatom or hcalendar? In-Reply-To: References: <1bc4603e0703221141x4748b03bnefd86b41f2e707de@mail.gmail.com> Message-ID: <338A3040-9CA7-4BEE-8AA8-C32C4F610382@placenamehere.com> On Mar 23, 2007, at 8:09 AM, Jeremy Keith wrote: > > But I'm not publishing an
already and isn't the whole > idea of microformats that we don't change *what* we're publishing, > just add more meaning to what we're already publishing? > > Of course, I can go ahead and add the hAtom classes anyway: > http://lifestream.adactio.com/ > > But that's not a valid hAtom feed. > > I have to say that I find it a little weird that author is required > but entry-title is not. Looking at the Atom spec, "title" is a > required feed element and "author" is recommended. For hAtom, > that's been inverted: > > http://atomenabled.org/developers/syndication/#requiredFeedElements > > This has probably been discussed before, right? If anybody has some > URLs pointing to previous discussions of this issue, that'd be much > appreciated. without touching on the core issues [way to early to think my way through the docs] looking at the page, though sparse, it does strike me that you are already posting URL, nick and potentially logo/photo [if you consider it such] in the following markup:
i'll leave you to decide how to best turn that into a vcard that that can be associated with the hatom feed [but expanding the scope of the hatom root node would avoid need for some things like use of the nearest in parent fallback. -- [ Chris Casciano ] [ chris@placenamehere.com ] [ http://placenamehere.com ] From brian.suda at gmail.com Fri Mar 23 04:46:04 2007 From: brian.suda at gmail.com (Brian Suda) Date: Fri Mar 23 04:46:07 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator In-Reply-To: <4603C690.5010305@xtra.co.nz> References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> <4603C690.5010305@xtra.co.nz> Message-ID: <21e770780703230546j6c8cfe7alc0f622d358234ebe@mail.gmail.com> On 3/23/07, Paul Wilkins wrote: > Henri Sivonen wrote: > > On Mar 10, 2007, at 23:10, Paul Wilkins wrote: > >> You are using the BibTex format, which is covered in the > >> citation formats http://microformats.org/wiki/citation-formats > > > > Sure, but considering that I share my .bib, should I expect people to > > want to scrape my (X)HTML-formatted bibliography? --- YES! if you ONLY offer the reference as a .bib file then you are locking people into having to use BibTeX. You can certainly offer the .bib file, but by marking-up the XHTML, then people can extract the semantics and create CSV, Dublin Core RDF, TXT, or other formats for free. You do NOT have to have 400 small icons saying "download as: ..." > If the .bib is used as the lone source for the XHTML, I suspect it would > be easier to scrape the .bib file. --- What i tend to do for things like vCards and iCalendars is to create a "static" link to a .vcf file and then with Mod_rewrite or other tools make that a Link to a service that converts the HTML to a .vcf The same can be done with a .bib file. That way when you update the HTML page, you do NOT have to update several other files as well since they are dynamically created from the single SOURCE XHTML file. -brian -- brian suda http://suda.co.uk From jeremy at adactio.com Fri Mar 23 05:07:36 2007 From: jeremy at adactio.com (Jeremy Keith) Date: Fri Mar 23 05:07:42 2007 Subject: [uf-discuss] Hatom or hcalendar? In-Reply-To: <21e523c20703230524x6a1663ddi29d278496bc11ed9@mail.gmail.com> References: <1bc4603e0703221141x4748b03bnefd86b41f2e707de@mail.gmail.com> <21e523c20703230524x6a1663ddi29d278496bc11ed9@mail.gmail.com> Message-ID: <16FDE484-8C44-422A-9E1E-18729336B683@adactio.com> David wrote: > No, this [1] is what you want to be looking at. > [1] http://atomenabled.org/developers/syndication/ > #recommendedEntryElements Ah, I stand corrected. I didn't read closely enough: "Names one author of the entry. An entry may have multiple authors. An entry must contain at least one author element unless there is an author element in the enclosing feed, or there is an author element in the enclosed source element." Thanks for the correction. Chris C. wrote: > without touching on the core issues [way to early to think my way > through the docs] looking at the page, though sparse, it does > strike me that you are already posting URL, nick and potentially > logo/photo [if you consider it such] in the following markup: > >
Good point. I'll get on that. Thanks. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From andy at pigsonthewing.org.uk Fri Mar 23 02:29:47 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 23 07:06:34 2007 Subject: [uf-discuss] http://microformats.org/wiki/hcard-issues in adr: singular or plural? Message-ID: Derek Pallas' "issue": adr says that all of it's properties are singular; however, "street-address" is listed as zero-or-more. has been on the 'wiki' for a few weeks, but I don't think it was ever raised here. Can anyone say which is correct, please? -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 23 02:35:20 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 23 07:06:35 2007 Subject: [uf-discuss] Geo extensions (Was: hCard for non-contact-able locations) In-Reply-To: <003301c76cdc$5d7ff3e0$0201a8c0@andrieuhome> References: <003301c76cdc$5d7ff3e0$0201a8c0@andrieuhome> Message-ID: In message <003301c76cdc$5d7ff3e0$0201a8c0@andrieuhome>, Joe Andrieu writes >If hCard 1.0 is locked, ok. I actually think that's totally >appropriate. Then, what's the process for hCard 1.1 or 2.0? > >Or more pertinant to recent conversations what is the process for Geo >2.0? Although hCard 1.0 locks Geo, it seems reasonable for a Geo 2.0 >to be considered. Note that there are currently two, separate, but not mutually exclusive, proposals to extend Geo: For non-Earth bodies: To add elevation (altitude): There has also been discussion of sequencing, for the publishing of trials/ directions or boundaries as a series of points defined by Geo. I'll attempt to capture the latter on the 'wiki', later, as: -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 23 04:56:36 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 23 07:06:35 2007 Subject: [uf-discuss] Hatom or hcalendar? In-Reply-To: References: <1bc4603e0703221141x4748b03bnefd86b41f2e707de@mail.gmail.com> Message-ID: In message , Jeremy Keith writes >So I started editing the template and I hit a snag: I don't have an >author listed for each entry. Author is required for hAtom. Now, I >could just put a single hCard somewhere within the hAtom feed and that >would solve the problem: > >From http://microformats.org/wiki/hatom: >"If the Entry Author is missing, find the Nearest In Parent
>element(s) with class name author and that is/are a valid hCard" > >But I'm not publishing an
already and isn't the whole idea >of microformats that we don't change *what* we're publishing, just add >more meaning to what we're already publishing? I can add a "+1" to that. When I came to add hAtom to several pages, for example: I had no author on the page. It prompted me to include a footer, with an hCard, in every age, which itself was a good thing, but that may have been either desirable nor possible. Furthermore, if people subscribe to the resultant feed, they don't even get to see the author details! -- Andy Mabbett Welcome to the world's longest week! From brian.suda at gmail.com Fri Mar 23 07:15:44 2007 From: brian.suda at gmail.com (Brian Suda) Date: Fri Mar 23 07:15:47 2007 Subject: [uf-discuss] http://microformats.org/wiki/hcard-issues in adr: singular or plural? In-Reply-To: References: Message-ID: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com> from: http://www.w3.org/2002/12/cal/rfc2426.html#sec3.2.1 The text components are separated by the SEMI-COLON character (ASCII decimal 59). Where it makes semantic sense, individual text components can include multiple text values (e.g., a "street" component with multiple lines) separated by the COMMA character (ASCII decimal 44). All the elements for an ADR appear to be zero or more. If you have multiple street-addresses on a page they will be concatenated together with a ',' and used as a single element in the ADR. The output will only have ONE street-address, but when they can be broken into many class="street-address" in the html. -brian On 3/23/07, Andy Mabbett wrote: > > Derek Pallas' "issue": > > adr says that all of it's > properties are singular; however, "street-address" is listed as > zero-or-more. > > has been on the 'wiki' for a > few weeks, but I don't think it was ever raised here. > > Can anyone say which is correct, please? > > -- > Andy Mabbett > > > Welcome to the world's longest week! > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- brian suda http://suda.co.uk From hsivonen at iki.fi Fri Mar 23 16:48:55 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Fri Mar 23 16:49:04 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator In-Reply-To: <4603C690.5010305@xtra.co.nz> References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> <4603C690.5010305@xtra.co.nz> Message-ID: <36CFFF25-F684-4F5C-A50D-E29AA206EB0E@iki.fi> On Mar 23, 2007, at 14:22, Paul Wilkins wrote: > Henri Sivonen wrote: >> On Mar 10, 2007, at 23:10, Paul Wilkins wrote: >>> You are using the BibTex format, which is covered in the >>> citation formats http://microformats.org/wiki/citation-formats >> Sure, but considering that I share my .bib, should I expect people >> to want to scrape my (X)HTML-formatted bibliography? > > If the .bib is used as the lone source for the XHTML, I suspect it > would be easier to scrape the .bib file. It is the lone source. >>> The citation microformat is a work in progress at this stage, so >>> it's not mature enough for programs to extract information from it, >> I guess this means that I shouldn't try to support hCite on the >> generator side in my thesis considering that the document should >> go final on the first week of April. > > Even though it goes final then, does that prevent you from later on > adding markup which doesn't affect the text, yet makes it easier > for tools to scrape through the information? There's no technical barrier to updating the file, but as a matter of archival principle, it seems wrong to tamper with the dated file later on. Tampering with it could lower the confidence of readers in the stability of the file as a version that corresponds exactly to the official paper version in the university department library. >> Would it be of any use to anyone if I wrapped the name of each >> author/ editor in a if I otherwise leave my >> markup the way it is now? > > A formatted name is quite a restricted format, and if the formatted > name doesn't follow a certain prescribed format, it is considered > to be invalid and isn't used. What about class='n'? > Currently the BibTeX is as follows > > @Misc{AXML, > editor = {Tim Bray and Jean Paoli and C.M. Sperberg-McQueen}, > title = {The Annotated XML 1.0 Specification}, > year = {1998}, > publisher = {O'Reilly Media, Inc.}, > refdate = {2007-03-04}, > url = {http://www.xml.com/pub/a/axml/axmlintro.html} > } > > From which you are wanting to create the following kind of data. > > [AXML] > The Annotated XML 1.0 Specification. Tim Bray, Jean Paoli and > C.M. Sperberg-McQueen, editors. O?Reilly Media, Inc., 1998. http:// > www.xml.com/pub/a/axml/axmlintro.html (referenced: 2007-03-04) > > The editor section alone will be interesting to markup, because the > citation will have to allow multiple editors, in which case both > the BibTeX and the microformat will have to be created from a > parent source, so that the microformat can gain the name-based > information in the format required, while still allowing that > information through to become the BibTeX file. The current markup is:
[AXML]
The Annotated XML 1.0 Specification. Tim Bray, Jean Paoli and C.M. Sperberg-McQueen, editors. O?Reilly Media, Inc., 1998. http://www.xml.com/ pub/a/axml/axmlintro.html (referenced: 2007-03-04)
So to extract the editors from Tim Bray, Jean Paoli and C.M. Sperberg-McQueen, one would need to know that it is OK to split on ", " and " and ". I could wrap each name in a span with a class. But what class? >>> The benefits are that people visitng your content with next >>> generation tools wil be able to easily extract and use the >>> information in more interesting and useful ways. >> So basically, my effort would not be about catering to specific >> realistic foreseeable use cases. Instead, it would be about >> putting data out there in case someone figures out a use case >> later on. > > It may be more useful to provide the ISBN number for the book. Then > the problems left to be solved become smaller and easier to handle. Sorry, but I don't follow. What's "the book"? >> Somehow, I was under the impression that hCite required >> bibliography items as
s instead of
/
pairs (which is >> what I use and what W3C and WHATWG specs use). > > I'm sure that design patterns can be created to accommodate such a > scheme. > >> What I'm trying to say is that I think hCite should allow names to >> be marked up as formatted names tossing the deformatting problem >> to the consumer. After all, one of the most popular bibliography >> data format, BibTeX, stores formatted names. > > Currently the formatted names are accepted in the following formats > > given-name (space) family-name > family-name (comma) given-name > family-name (comma) given-name-first-initial > family-name (space) given-name-first-initial (optional period) In the .bib, there are names that don't follow those formats. For example: Michael I. Schwartzbach C. M. Sperberg-McQueen Arnaud Le Hors Simon St. Laurent H?kon Wium Lie Geert Jan Bex Jan Van den Bussche Henrik Frystyk Nielsen Roy Thomas Fielding I'd rather not develop heuristics in my end for properly guessing the semantics of the middle tokens. Especially when it is uncertain if anyone will ever scape my bibliography with a tool that both needed and understood semantic encoding of the different parts of the name. > How much granularity does BibTeX allow for when storing the > formated names for Editors? I don't know what's officially allowed. My generator uses UTF-8- encoded .bib, which is already stretching things a bit. In general, you just write names in .bib in the usual little-endian European format and BibTeX does some magic. I guess that in the real BibTeX, there are heuristics for Dutch surnames (van der) and the like. I am using a format where the given name comes first and the family name comes last and whatever middle stuff is provided in the name of the author on the work itself goes in the middle. C. M. Sperberg- McQueen mentioned above is an exception, because the first name is deliberately not provided in full. The output format I use is intentionally lossless, so the given name isn't truncated and the name surname isn't reordered. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From justin at classsoftware.com Fri Mar 23 21:44:31 2007 From: justin at classsoftware.com (Justin Mclean) Date: Fri Mar 23 21:44:43 2007 Subject: [uf-discuss] hCards in other languages Message-ID: Hi there, I have a simple site (http://www.classsoftware.com) on which I've added a vCard, the card seems to work fine in Operator (firefox plugin) but in the Japanese version of the page (http:// www.classsoftware.com/index.cfm/lang/ja) with exactly the same XHTML structure the imported card is missing the org name and my name. Is something wrong with the hCard on the page or is it an issue with Operator? Also what is the best way to mark up a hCard when the content of the card is in an langauge other than english? Do you need to specify the language used in the card (lang attribute on the card's container) or is the language of the of HTML page (the lang attribute on the html tag) good enough? Thanks, Justin From ianb at colorstudy.com Fri Mar 23 22:42:50 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Fri Mar 23 22:42:54 2007 Subject: [uf-discuss] hReview type=review Message-ID: <4604C86A.9070309@colorstudy.com> So, I've been thinking about things you can do with reviews to collect content (http://mailman.laptop.org/pipermail/library/2007-March/000041.html) and how you might want to say "get all the content someone else has collected". And, apropos to this group, how the source for a collection of content can just be a bunch of hreviews (plus some criteria, e.g., a set of tags or ratings). A technique I thought of for getting other people's content be to allow recursive reviews. That is:
Include review: ...
And adding things like tags to this metareview is actually quite interesting and useful -- like saying that this person's reviews are related to a particular tag. Or a rating implies the reviews have a certain validity (for weighing multiple ratings, or I suppose determining the accuracy of their ratings -- standard deviation? I don't know how I'd use a standard deviation in ratings, and yet it also seems somehow natural.) Anyway, a thought. And I suppose a proposal for another type. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers From hsivonen at iki.fi Sat Mar 24 02:05:42 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Sat Mar 24 02:05:49 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator In-Reply-To: <21e770780703230546j6c8cfe7alc0f622d358234ebe@mail.gmail.com> References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> <4603C690.5010305@xtra.co.nz> <21e770780703230546j6c8cfe7alc0f622d358234ebe@mail.gmail.com> Message-ID: <41AA18E7-A7C4-4438-B90B-38379CA55577@iki.fi> On Mar 23, 2007, at 14:46, Brian Suda wrote: >>> Sure, but considering that I share my .bib, should I expect >>> people to >>> want to scrape my (X)HTML-formatted bibliography? > > --- YES! if you ONLY offer the reference as a .bib file then you are > locking people into having to use BibTeX. For the time being, I'd guess that .bib is better supported than hCite. > That way when you update the > HTML page, you do NOT have to update several other files as well since > they are dynamically created from the single SOURCE XHTML file. In my case, the .bib is the source file. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Sat Mar 24 02:22:35 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Sat Mar 24 02:22:41 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator In-Reply-To: <36CFFF25-F684-4F5C-A50D-E29AA206EB0E@iki.fi> References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> <4603C690.5010305@xtra.co.nz> <36CFFF25-F684-4F5C-A50D-E29AA206EB0E@iki.fi> Message-ID: On Mar 24, 2007, at 02:48, Henri Sivonen wrote: > The current markup is: >
[AXML]
The Annotated XML 1.0 > Specification. Tim Bray, Jean Paoli > and C.M. Sperberg-McQueen, editors. class="publisher">O?Reilly Media, Inc., class="year">1998. http:// > www.xml.com/pub/a/axml/axmlintro.html (referenced: class="refdate">2007-03-04)
> > So to extract the editors from Tim Bray, Jean > Paoli and C.M. Sperberg-McQueen, one would need to know that > it is OK to split on ", " and " and ". I could wrap each name in a > span with a class. But what class? Rephrasing: How would I need to change my markup to comply with what hCite is currently expected to be? If I do that now, will I pollute the space of future hCite data? Other examples of my current markup:

[Cascading]
Cascading Style Sheets. H?kon Wium Lie. PhD thesis, University of Oslo, 2005. http:// people.opera.com/howcome/2006/phd/ (referenced: 2007-02-26)

[Computable]
On computable numbers, with an application to the Entscheidungsproblem. Alan M. Turing. In Proceedings of the London Mathematical Society, series 2, volume 42, pages 230?265. London Mathematical Society, 1937. http:// www.turingarchive.org/browse.php/B/12 (referenced: 2007-03-03)

[Microformats]
Microformats: a pragmatic path to the semantic web. Rohit Khare and Tantek ?elik. In WWW ?06: Proceedings of the 15th international conference on World Wide Web, pages 865?866. ACM Press, 2006. ISBN: 1-59593-323-9. http:// doi.acm.org/10.1145/1135777.1135917

-- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From paul_wilkins at xtra.co.nz Sat Mar 24 02:32:41 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sat Mar 24 02:32:45 2007 Subject: [uf-discuss] hCards in other languages In-Reply-To: References: Message-ID: <4604FE49.4000108@xtra.co.nz> Justin Mclean wrote: > Hi there, > > I have a simple site (http://www.classsoftware.com) on which I've added > a vCard, the card seems to work fine in Operator (firefox plugin) but > in the Japanese version of the page (http:// > www.classsoftware.com/index.cfm/lang/ja) with exactly the same XHTML > structure the imported card is missing the org name and my name. Is > something wrong with the hCard on the page or is it an issue with > Operator? Works for me on Operator 0.6.2 and on X2V at http://suda.co.uk/projects/X2V/ > Also what is the best way to mark up a hCard when the content of the > card is in an langauge other than english? Do you need to specify the > language used in the card (lang attribute on the card's container) or > is the language of the of HTML page (the lang attribute on the html > tag) good enough? Yes, that's good enough. The only difficulty is when english text is expected as keywords, and you want them displayed in another language instead. Then you'd have to do something like fakusu -- Paul Wilkins From paul_wilkins at xtra.co.nz Sat Mar 24 02:38:30 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sat Mar 24 02:38:37 2007 Subject: [uf-discuss] hCite elevator pitch and my bibliography generator In-Reply-To: References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> <4603C690.5010305@xtra.co.nz> <36CFFF25-F684-4F5C-A50D-E29AA206EB0E@iki.fi> Message-ID: <4604FFA6.7000300@xtra.co.nz> Henri Sivonen wrote: > Rephrasing: > How would I need to change my markup to comply with what hCite is > currently expected to be? If I do that now, will I pollute the space of > future hCite data? As far as I'm aware, the architectural plans are still being drawn up for hCite. It is currently still a work-in-progress, with property names not yet created. The best advice I can give for you is, watch this space. -- Paul Wilkins From justin at classsoftware.com Sat Mar 24 03:02:18 2007 From: justin at classsoftware.com (Justin Mclean) Date: Sat Mar 24 03:02:31 2007 Subject: [uf-discuss] hCards in other languages In-Reply-To: <4604FE49.4000108@xtra.co.nz> References: <4604FE49.4000108@xtra.co.nz> Message-ID: <87237DB5-B642-48EB-BEE7-E51185E2CCFE@classsoftware.com> Hi Paul, > Works for me on Operator 0.6.2 and on X2V at http://suda.co.uk/ > projects/X2V/ Thanks for that, X2V worked for me also so that implies that the hCard on the page is fine. Out of interest what address program are you using? > Yes, that's good enough. The only difficulty is when english text > is expected as keywords, and you want them displayed in another > language instead. Then you'd have to do something like > > fakusu Yes that's what I'm using in the japanese (and other language) versions. The address is still in english so I guess I should tag that as lang="en" (or perhaps en-au) as it's a different language to the page. Thanks, Justin From paul_wilkins at xtra.co.nz Sat Mar 24 15:05:51 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sat Mar 24 15:05:57 2007 Subject: [uf-discuss] hCards in other languages In-Reply-To: <87237DB5-B642-48EB-BEE7-E51185E2CCFE@classsoftware.com> References: <4604FE49.4000108@xtra.co.nz> <87237DB5-B642-48EB-BEE7-E51185E2CCFE@classsoftware.com> Message-ID: <4605AECF.8040703@xtra.co.nz> Justin Mclean wrote: > Hi Paul, > >> Works for me on Operator 0.6.2 and on X2V at http://suda.co.uk/ >> projects/X2V/ > > Thanks for that, X2V worked for me also so that implies that the hCard > on the page is fine. Out of interest what address program are you using? Currently I'm using Microsoft Outlook, but I'll be changing that shortly. >> fakusu > > Yes that's what I'm using in the japanese (and other language) > versions. The address is still in english so I guess I should tag that > as lang="en" (or perhaps en-au) as it's a different language to the page. That's right. If you're using HTML then use lang="en-au" If you're using XHTML 1.1 then use xml:lang="en-au" If you're using XHTML 1.0 then use both together. -- Paul Wilkins From john at proionta.gr Sat Mar 24 15:53:10 2007 From: john at proionta.gr (John) Date: Sat Mar 24 15:53:13 2007 Subject: [uf-discuss] An idea for an application Message-ID: <4605B9E6.1080108@proionta.gr> I just thought of a possible application for hcard: A Mozilla plugin would allow you to enter a URL for a person instead of full details in the addressboox. Then Thunderbird would check with that webpage regularly and see if their e-mail address has changed to update its addressbook. From angus at pobox.com Sat Mar 24 17:33:20 2007 From: angus at pobox.com (Angus McIntyre) Date: Sat Mar 24 17:33:24 2007 Subject: [uf-discuss] An idea for an application In-Reply-To: <4605B9E6.1080108@proionta.gr> References: <4605B9E6.1080108@proionta.gr> Message-ID: <42059.151.202.81.65.1174786400.squirrel@webmail.nomadcode.com> On Sat, March 24, 2007 6:53 pm, John wrote: > I just thought of a possible application for hcard: > > A Mozilla plugin would allow you to enter a URL for a person instead of > full details in the addressboox. Then Thunderbird would check with that > webpage regularly and see if their e-mail address has changed to update > its addressbook. One problem here is that many people may be unwilling to publish their email addresses on a web page, because of the certainty that the address will be picked up by spammers. This may limit the number of cases where this would be useful. Incidentally, one workaround I'm currently using with hCard is to write the email addresses in human-intelligible format - 'user' at 'example' dot 'com' or similar - but give the element a unique ID. Once page load completes, a Javascript changes the 'innerHTML' for the element to an actual link. Visitors to the page see a clickable link, the correct address is accessible to the Operator extension, and it degrades gracefully for users who don't have Javascript. However, spammers - who don't yet seem to have put Javascript engines into their crawlers - don't see the address. The half-life of this trick isn't infinite - sooner or later spammers will catch up - but it seems to work reasonably well at the moment. Angus From john at proionta.gr Sat Mar 24 19:12:07 2007 From: john at proionta.gr (John) Date: Sat Mar 24 19:12:17 2007 Subject: [uf-discuss] An idea for an application In-Reply-To: <42059.151.202.81.65.1174786400.squirrel@webmail.nomadcode.com> References: <4605B9E6.1080108@proionta.gr> <42059.151.202.81.65.1174786400.squirrel@webmail.nomadcode.com> Message-ID: <4605E887.6050104@proionta.gr> Angus McIntyre wrote: > On Sat, March 24, 2007 6:53 pm, John wrote: > >> I just thought of a possible application for hcard: >> >> A Mozilla plugin would allow you to enter a URL for a person instead of >> full details in the addressboox. Then Thunderbird would check with that >> webpage regularly and see if their e-mail address has changed to update >> its addressbook. >> > > One problem here is that many people may be unwilling to publish their > email addresses on a web page, because of the certainty that the address > will be picked up by spammers. This may limit the number of cases where > this would be useful. I can't see that as a problem to not go ahead. I receive over 300 spam a day and am doing okay. Most people probably don't have the technology required to deal with that level of spam, but many do - they can place their hcards on their website in any form, and everyone will benefit from that - both the website owners, and the people who communicate with them. And the fact that employing anti-spam technology allows you to place your hcard in the open, will entice more people to employ anti-spam measures. From andy at pigsonthewing.org.uk Fri Mar 23 11:04:38 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 11:27:56 2007 Subject: [uf-discuss] Mark-up for vCard in table rows Message-ID: I'm advising someone on marking up some content, where each table row refers to a specific place. Stripped of extraneous detail, the markup looks like:
Okhaldhunga is a place ("locality") and Nepal, obviously, the "country-name". "Visitor Center" will be the "fn org". The URLs are to maps, and need not be marked-up in the hCard. Given that the only place class="vcard" can go is the , where can I put class="adr"? -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 23 11:11:51 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 11:27:57 2007 Subject: [uf-discuss] http://microformats.org/wiki/hcard-issues in adr: singular or plural? In-Reply-To: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com> References: <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com> Message-ID: <6UFkM1l3ZCBGFwsl@pigsonthewing.org.uk> In message <21e770780703230815r5aef74cei1fbe76fb803c4cf5@mail.gmail.com>, Brian Suda writes >All the elements for an ADR appear to be zero or more. > >If you have multiple street-addresses on a page they will be >concatenated together with a ',' and used as a single element in the >ADR. That may work for street-address, but it won't work for postcode or post-office-box (in at least some territories, the comma would invalidate both). Are there any country-names where a comma is used? I seem to recall Operator barfing, when I used two locality attributes, previously. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 23 11:41:03 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 11:27:57 2007 Subject: [uf-discuss] Real vs. stage names Message-ID: <1U7ns6nP1CBGFwsD@pigsonthewing.org.uk> How would folks mark up an hCard for the singer Alvin Stardust, born Bernard William Jewry, also known under the stage name Shane Fenton? With two nicknames? If so, which way round? -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Sat Mar 24 03:19:01 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 11:27:58 2007 Subject: [uf-discuss] mark-up formatting in e-mail (was: hCite elevator pitch and my bibliography generator) In-Reply-To: References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> <4603C690.5010305@xtra.co.nz> <36CFFF25-F684-4F5C-A50D-E29AA206EB0E@iki.fi> Message-ID: In message , Henri Sivonen writes >
[Cascading]
Cascading Style >Sheets. H?kon Wium Lie. PhD >thesis, University of Oslo, class="year">2005. http:// people.opera.co >m/howcome/2006/phd/ (referenced: 2007-02-26< >/span>)
Please - everyone - format your mark-up examples to be readable in plain text e-mails. For example:
[Cascading]
Cascading Style Sheets. H?kon Wium Lie. PhD thesis, University of Oslo, 2005. http:// people.opera.com/howcome/2006/phd/ (referenced: 2007-02-26)
You might also remove extraneous detail, so that : http:// people.opera.com/howcome/2006/phd/ becomes: ... Thank you. I suggest that this request be written into the mailing list policies. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Sun Mar 25 02:57:39 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 11:27:59 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <0cpnOiOCiQAGFwkj@pigsonthewing.org.uk> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <006b01c76b4b$40911e40$bc08a8c0@nzto22> <923a87360703201800x1b28f591t5f3de070e456e78e@mail.gmail.com> <008201c76b58$57347c20$bc08a8c0@nzto22> <0cpnOiOCiQAGFwkj@pigsonthewing.org.uk> Message-ID: In message <0cpnOiOCiQAGFwkj@pigsonthewing.org.uk>, Andy Mabbett writes >> T?l?c.: >> (514) 123-4568 A further thought - this wouldn't be an issue, if we had separate classes, rather than one class and several types, thus: (514) 555-4561 (514) 555-4562 (514) 555-4563 (514) 555-4564 While there are obviously practical limits to the number of options a single uF can use, for cases where there are only a few alternatives, such as this one it's worth bearing in mind, as future uFs are developed. -- Andy Mabbett Welcome to the world's longest week! From jason at sixtwothree.org Sun Mar 25 11:47:59 2007 From: jason at sixtwothree.org (Jason Garber) Date: Sun Mar 25 11:48:03 2007 Subject: [uf-discuss] Mark-up for vCard in table rows In-Reply-To: References: Message-ID: <4606D1EF.9040604@sixtwothree.org> You "should" be able to put class="adr" in multiple times and still get a complete and/or valid address. I did a real brief test using multiple spans with classes of "adr" and Operator didn't blow up and Tails still recognizes a complete address. In Operator, though, it does list out multiple objects under the "object adr". The one hangup I did find was importing the contact into Address Book (mac) results in multiple addresses, so this may not be the perfect solution. Jason jason@sixtwothree.org Andy Mabbett wrote: > I'm advising someone on marking up some content, where each table row > refers to a specific place. > > Stripped of extraneous detail, the markup looks like: > > > > > > > > > > > > Okhaldhunga is a place ("locality") and Nepal, obviously, the > "country-name". "Visitor Center" will be the "fn org". > > The URLs are to maps, and need not be marked-up in the hCard. > > Given that the only place class="vcard" can go is the , where can I > put class="adr"? > > From paul_wilkins at xtra.co.nz Sun Mar 25 12:08:49 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 12:09:00 2007 Subject: [uf-discuss] Mark-up for vCard in table rows In-Reply-To: References: Message-ID: <4606D6D1.6040401@xtra.co.nz> Andy Mabbett wrote: > Given that the only place class="vcard" can go is the , where can I > put class="adr"? If you have to stick to using tables (ugh), you can nest them together. My mother always said tables would be bad for my health. -- Paul Wilkins From tantek at cs.stanford.edu Sun Mar 25 12:53:09 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Mar 25 12:53:06 2007 Subject: [uf-discuss] Real vs. stage names In-Reply-To: <1U7ns6nP1CBGFwsD@pigsonthewing.org.uk> Message-ID: On 3/23/07 12:41 PM, "Andy Mabbett" wrote: > > How would folks mark up an hCard for the singer Alvin Stardust, born > Bernard William Jewry, also known under the stage name Shane Fenton? > > > > With two nicknames? If so, which way round? What's his passport look like? That would answer the given-name, family-name questions, and perhaps even the additional-name and nickname questions. Tantek From tantek at cs.stanford.edu Sun Mar 25 13:24:04 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Mar 25 13:24:02 2007 Subject: using class to store type value (was Re: [uf-discuss] An Inconvenient hCard) In-Reply-To: Message-ID: On 3/25/07 3:57 AM, "Andy Mabbett" wrote: > In message <0cpnOiOCiQAGFwkj@pigsonthewing.org.uk>, Andy Mabbett > writes > >>> T?l?c.: >>> (514) 123-4568 > > A further thought - this wouldn't be an issue, if we had separate > classes, rather than one class and several types, thus: > > (514) 555-4561 > > (514) 555-4562 > > (514) 555-4563 > > (514) 555-4564 This was actually initially attempted and rejected because it constituted storage of content in the class attribute, which is an anti-design-pattern. The "type" in this case is essentially a "tag" on the phone number, which is human readable content. The resolution is not in an easily discoverable place unfortunately: http://microformats.org/wiki/hcard-parsing#ISSUE_2 Thus I am adding it to the hCard FAQ. Thanks, Tantek From tantek at cs.stanford.edu Sun Mar 25 13:36:04 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Mar 25 13:36:00 2007 Subject: [uf-discuss] mark-up formatting in e-mail (was: hCite elevator pitch and my bibliography generator)) In-Reply-To: Message-ID: On 3/24/07 4:19 AM, "Andy Mabbett" wrote: > In message , Henri Sivonen > writes > >>
[Cascading]
Cascading Style >> Sheets. H?kon Wium Lie. PhD >> thesis, University of Oslo, > class="year">2005. http:// people.opera.co >> m/howcome/2006/phd/ (referenced: 2007-02-26< >> /span>)
> > Please - everyone - format your mark-up examples to be readable in plain > text e-mails. For example: > >
[Cascading]
> >
> > class="title">Cascading Style Sheets. > > H?kon Wium Lie. PhD thesis, > > University of Oslo, > > 2005. > > > > class="url">http:// people.opera.com/howcome/2006/phd/ > > (referenced: > > 2007-02-26) > >
> > You might also remove extraneous detail, so that : > > class="url">http:// people.opera.com/howcome/2006/phd/ > > becomes: > > ... > > Thank you. > > I suggest that this request be written into the mailing list policies. It is a good suggestion to request that markup examples have whitespace added for readability. Added to mailing-list wiki page: http://microformats.org/wiki/mailing-lists#General_guidelines Thanks, Tantek From andy at pigsonthewing.org.uk Sun Mar 25 13:32:08 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 13:43:44 2007 Subject: [uf-discuss] Mark-up for vCard in table rows In-Reply-To: <4606D6D1.6040401@xtra.co.nz> References: <4606D6D1.6040401@xtra.co.nz> Message-ID: In message <4606D6D1.6040401@xtra.co.nz>, Paul Wilkins writes >Andy Mabbett wrote: >> Given that the only place class="vcard" can go is the , where can I >> put class="adr"? > >If you have to stick to using tables (ugh), you can nest them together. I don't - but then, it's not my website. Then again, what's wrong with tables fir tabular data? > > > > I'm trying to advise someone about marking up an existing table; uFs are not supposed to require the re-engineering of valid HTML. -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Sun Mar 25 13:32:35 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 13:43:45 2007 Subject: [uf-discuss] Real vs. stage names In-Reply-To: References: <1U7ns6nP1CBGFwsD@pigsonthewing.org.uk> Message-ID: In message , Tantek ?elik writes >On 3/23/07 12:41 PM, "Andy Mabbett" wrote: > >> >> How would folks mark up an hCard for the singer Alvin Stardust, born >> Bernard William Jewry, also known under the stage name Shane Fenton? >> >> >> >> With two nicknames? If so, which way round? > >What's his passport look like? Oddly enough, he's never sent it to me. > That would answer the given-name, family-name questions, and perhaps >even the additional-name and nickname questions. And otherwise? -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Sun Mar 25 13:37:32 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 13:43:46 2007 Subject: [uf-discuss] Mark-up for vCard in table rows In-Reply-To: <4606D1EF.9040604@sixtwothree.org> References: <4606D1EF.9040604@sixtwothree.org> Message-ID: In message <4606D1EF.9040604@sixtwothree.org>, Jason Garber writes >You "should" be able to put class="adr" in multiple times and still get >a complete and/or valid address. Thank you. Is that documented anywhere? I would understand multiple "adr" to refer to *different* addresses ("my house in the city and my apartment at the beach"). >I did a real brief test using multiple spans with classes of "adr" and >Operator didn't blow up and Tails still recognizes a complete address. > >In Operator, though, it does list out multiple objects under the >"object adr". If your interpretation of multiple "adr" being concatenated to one address is correct, than that is "blowing up". -- Andy Mabbett Welcome to the world's longest week! From tantek at cs.stanford.edu Sun Mar 25 13:56:11 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Mar 25 13:56:07 2007 Subject: each "adr" is its own address (was Re: [uf-discuss] Mark-up for vCard in table rows) In-Reply-To: Message-ID: On 3/25/07 2:37 PM, "Andy Mabbett" wrote: > In message <4606D1EF.9040604@sixtwothree.org>, Jason Garber > writes > >> You "should" be able to put class="adr" in multiple times and still get >> a complete and/or valid address. vCards can contain multiple ADR properties for multiple addresses. Thus in hCard, multiple class="adr" instances are for multiple addresses, not concatenation into a single address. Each class="adr" indicates a separate address. Added to FAQ: http://microformats.org/wiki/hcard-faq#How_do_I_markup_multiple_addresses >> I did a real brief test using multiple spans with classes of "adr" and >> Operator didn't blow up and Tails still recognizes a complete address. >> >> In Operator, though, it does list out multiple objects under the >> "object adr". > > If your interpretation of multiple "adr" being concatenated to one > address is correct, than that is "blowing up". The concatenation interpretation of "adr" is incorrect. Thanks, Tantek From paul_wilkins at xtra.co.nz Sun Mar 25 13:59:56 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 14:00:00 2007 Subject: [uf-discuss] Mark-up for vCard in table rows References: <4606D6D1.6040401@xtra.co.nz> Message-ID: <002201c76f28$ed327370$bc08a8c0@nzto22> From: "Andy Mabbett" > I'm trying to advise someone about marking up an existing table; uFs are > not supposed to require the re-engineering of valid HTML. http://microformats.org/wiki/hcard-parsing Other properties, like "adr", "email", "url", "tel", etc., may (and often do) appear more than once, and thus the parser continues to look for each occurrence within the contents of the hCard So you can mark it up properly, with a class="adr" on each appropriate td. If the tool doesn't correctly take the multiple instances and bring them together, that ais a problem that the tool will need to remedy. -- Paul Wilkins From jason at sixtwothree.org Sun Mar 25 14:01:47 2007 From: jason at sixtwothree.org (Jason Garber) Date: Sun Mar 25 14:01:52 2007 Subject: [uf-discuss] Mark-up for vCard in table rows In-Reply-To: References: <4606D1EF.9040604@sixtwothree.org> Message-ID: <4606F14B.30001@sixtwothree.org> Andy Mabbett wrote: > In message <4606D1EF.9040604@sixtwothree.org>, Jason Garber > writes > >> You "should" be able to put class="adr" in multiple times and still >> get a complete and/or valid address. > > Thank you. Is that documented anywhere? I would understand multiple > "adr" to refer to *different* addresses ("my house in the city and my > apartment at the beach"). The hCard cheetsheat[1] notes that "adr" should "match 0 or more times" but to your point, this is probably to handle multiple addresses, not split-up single addresses. >> I did a real brief test using multiple spans with classes of "adr" >> and Operator didn't blow up and Tails still recognizes a complete >> address. >> >> In Operator, though, it does list out multiple objects under the >> "object adr". > > If your interpretation of multiple "adr" being concatenated to one > address is correct, than that is "blowing up". On further reflection, I'm not sure my suggestion will work since multiple "adr" blocks would logically indicate multiple addresses. Unless anyone knows of a concatenation method, of course. [1] http://microformats.org/wiki/hcard-cheatsheet Jason jason@sixtwothree.org From paul_wilkins at xtra.co.nz Sun Mar 25 14:02:10 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 14:02:14 2007 Subject: each "adr" is its own address (was Re: [uf-discuss] Mark-up forvCard in table rows) References: Message-ID: <002701c76f29$3cefcfc0$bc08a8c0@nzto22> From: "Tantek ? elik" > vCards can contain multiple ADR properties for multiple addresses. Thus > in > hCard, multiple class="adr" instances are for multiple addresses, not > concatenation into a single address. Each class="adr" indicates a > separate > address. What kind of solution would you propose then for Andy's table layout dilemma? -- Paul Wilkins From paul_wilkins at xtra.co.nz Sun Mar 25 14:05:21 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 14:05:26 2007 Subject: [uf-discuss] Mark-up for vCard in table rows References: <4606D6D1.6040401@xtra.co.nz> <002201c76f28$ed327370$bc08a8c0@nzto22> Message-ID: <002c01c76f29$aeb02470$bc08a8c0@nzto22> From: "Paul Wilkins" > http://microformats.org/wiki/hcard-parsing > Other properties, like "adr", "email", "url", "tel", etc., may (and often > do) appear more than once, and thus the parser continues to look for each > occurrence within the contents of the hCard > > So you can mark it up properly, with a class="adr" on each appropriate td. Sorry, correction, thanks Tantek, separate adr sections are for separate addresses. -- Paul Wilkins From jason at sixtwothree.org Sun Mar 25 14:14:34 2007 From: jason at sixtwothree.org (Jason Garber) Date: Sun Mar 25 14:14:38 2007 Subject: each "adr" is its own address (was Re: [uf-discuss] Mark-up forvCard in table rows) In-Reply-To: <002701c76f29$3cefcfc0$bc08a8c0@nzto22> References: <002701c76f29$3cefcfc0$bc08a8c0@nzto22> Message-ID: <4606F44A.9030504@sixtwothree.org> Paul Wilkins wrote: > From: "Tantek ? elik" >> vCards can contain multiple ADR properties for multiple addresses. >> Thus in >> hCard, multiple class="adr" instances are for multiple addresses, not >> concatenation into a single address. Each class="adr" indicates a >> separate >> address. > > What kind of solution would you propose then for Andy's table layout > dilemma? Would setting the "type" for each ADR solve this? I'm thinking not, since you could potentially have two work addresses, etc. but this (as far as I can discern) might be the closest to a solution. Jason jason@sixtwothree.org From paul_wilkins at xtra.co.nz Sun Mar 25 14:16:09 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 14:16:13 2007 Subject: [uf-discuss] Mark-up for vCard in table rows References: <4606D6D1.6040401@xtra.co.nz> Message-ID: <003901c76f2b$311e3a90$bc08a8c0@nzto22> From: "Andy Mabbett" > I'm trying to advise someone about marking up an existing table; uFs are > not supposed to require the re-engineering of valid HTML. Modern markup techniques can't be expected to work with ancient coding troubles. The only way to group address parts in separate td elements is to group them from the tr element. With the adr class in the tr element, the hcard grouping has to be further up, so with the current manner of marking up microformats, the table code you're working with isn't able to be marked up without modification. A way of successfully marking it up is to combine the td elements together, and use div and span to adjust the layout with css. But if you want to mark up the original code with no structural changes, because of the structured nature of microformats, that won't be possible. -- Paul Wilkins From andy at pigsonthewing.org.uk Sun Mar 25 14:09:06 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 25 14:24:30 2007 Subject: [uf-discuss] Mark-up for vCard in table rows In-Reply-To: <4606F14B.30001@sixtwothree.org> References: <4606D1EF.9040604@sixtwothree.org> <4606F14B.30001@sixtwothree.org> Message-ID: In message <4606F14B.30001@sixtwothree.org>, Jason Garber writes >I'm not sure my suggestion will work since multiple "adr" blocks would >logically indicate multiple addresses. Unless anyone knows of a >concatenation method, of course. There's the "include -pattern", but that would seem to be a sledgehammer, to crack this particular nut (the URL of which I'm not at liberty to divulge - I'll ask if I may). -- Andy Mabbett Welcome to the world's longest week! From jason at sixtwothree.org Sun Mar 25 14:38:44 2007 From: jason at sixtwothree.org (Jason Garber) Date: Sun Mar 25 14:38:49 2007 Subject: [uf-discuss] Mark-up for vCard in table rows In-Reply-To: References: <4606D6D1.6040401@xtra.co.nz> Message-ID: <4606F9F4.1050208@sixtwothree.org> Andy Mabbett wrote: >> >> >> >> > > I'm trying to advise someone about marking up an existing table; uFs > are not supposed to require the re-engineering of valid HTML. This is a stretch, but you could wrap each row in a tag and give _that_ a class of "hcard", then your could have a class of "adr." It's hack-ish and adds a lot to the table, but is still valid and could solve the problem. Quick and dirty example:
Visitor Center Nepal Okhaldhunga (40 km) map

Visitor Center Nepal Okhaldhunga (40 km) map
Visitor Center
Nepal Okhaldhunga (40 km) map

Visitor Center > > >
> Nepal Okhaldhunga (40 km) > map

Visitor Center

Nepal

Okhaldhunga (40 km) map

Visitor Center >> >> >>
>> Nepal Okhaldhunga (40 km) >> map

Jason Garber Vienna VA

Andy Mabbett Sometown Somewhere

Hopefully that doesn't get mungled format-wise, but could this maybe be a solution? Jason jason@sixtwothree.org From jason at sixtwothree.org Sun Mar 25 14:54:20 2007 From: jason at sixtwothree.org (Jason Garber) Date: Sun Mar 25 14:54:25 2007 Subject: [uf-discuss] Mark-up for vCard in table rows In-Reply-To: <4606F9F4.1050208@sixtwothree.org> References: <4606D6D1.6040401@xtra.co.nz> <4606F9F4.1050208@sixtwothree.org> Message-ID: <4606FD9C.9010709@sixtwothree.org> Jason Garber wrote: > Quick and dirty example: > > > > > > > > > > > > > > > > >
Jason Garber Vienna VA
Andy Mabbett Sometown Somewhere
Correction: those classes should be "vcard", not "hcard". Jason jason@sixtwothree.org From paul_wilkins at xtra.co.nz Sun Mar 25 15:11:05 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 15:11:10 2007 Subject: [uf-discuss] Mark-up for vCard in table rows References: <4606D6D1.6040401@xtra.co.nz> <4606F9F4.1050208@sixtwothree.org> <4606FD9C.9010709@sixtwothree.org> Message-ID: <005801c76f32$ddc1c4e0$bc08a8c0@nzto22> From: "Jason Garber" > Correction: those classes should be "vcard", not "hcard". yeah, that could work. Andy - how would you feel with the following sample code for your particular trouble. Visitor Center Nepal Okhaldhunga (40 km) map -- Paul Wilkins From paul_wilkins at xtra.co.nz Sun Mar 25 22:18:06 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Sun Mar 25 22:18:11 2007 Subject: [uf-discuss] Real vs. stage names In-Reply-To: References: <1U7ns6nP1CBGFwsD@pigsonthewing.org.uk> Message-ID: <4607659E.1030407@xtra.co.nz> Andy Mabbett wrote: > Tantek ?elik writes >> Andy Mabbett wrote: >>> How would folks mark up an hCard for the singer Alvin Stardust, born >>> Bernard William Jewry, also known under the stage name Shane Fenton? >> What's his passport look like? > Oddly enough, he's never sent it to me. >> That would answer the given-name, family-name questions, and perhaps >> even the additional-name and nickname questions. > And otherwise? And otherwise, like this. Start with what you know.
singer Alvin Stardust, Bernard William Jewry, also known under the stage name Shane Fenton.
Markup what you can, like the persons name
singer Alvin Stardust, Bernard William Jewry, also known under the stage name Shane Fenton.
Then you move on to nicknames The cheatsheet on the wiki at http://microformats.org/wiki/hcard-cheatsheet says nicknames can match 0 or more times, and just to make sure, RFC2426 which defined the vCard spec says about Nicknames: Type value: One or more text values separated by a COMMA character So if multiple nicknames are listed, they'll end up being comma separated.
singer Alvin Stardust, Bernard William Jewry, also known under the stage name Shane Fenton.
And finally you can sprinkle other things, like his role and stagename
singer Alvin Stardust, Bernard William Jewry, also known under the stage name Shane Fenton .
-- Paul Wilkins From mail at yasuhisa.com Mon Mar 26 07:01:01 2007 From: mail at yasuhisa.com (Yasuhisa Hasegawa) Date: Mon Mar 26 07:01:05 2007 Subject: [uf-discuss] An idea for an application In-Reply-To: <4605E887.6050104@proionta.gr> References: <4605B9E6.1080108@proionta.gr> <42059.151.202.81.65.1174786400.squirrel@webmail.nomadcode.com> <4605E887.6050104@proionta.gr> Message-ID: <706B7E17-E915-4EE4-B7F9-AA2A4DDB5683@yasuhisa.com> Hi. Plugin can be interesting implementation. I also would like to see in desktop app. I put up some ideas on Flickr a while ago. It's not exactly what you're talking about, but somewhat similar. http://www.flickr.com/photos/yhassy/sets/72157594321694651/ Regards -- Yasuhisa Hasegawa http://www.yasuhisa.com/ On 2007/03/25, at 12:12, John wrote: > Angus McIntyre wrote: >> On Sat, March 24, 2007 6:53 pm, John wrote: >> >>> I just thought of a possible application for hcard: >>> >>> A Mozilla plugin would allow you to enter a URL for a person >>> instead of >>> full details in the addressboox. Then Thunderbird would check >>> with that >>> webpage regularly and see if their e-mail address has changed to >>> update >>> its addressbook. >>> >> >> One problem here is that many people may be unwilling to publish >> their >> email addresses on a web page, because of the certainty that the >> address >> will be picked up by spammers. This may limit the number of cases >> where >> this would be useful. > > I can't see that as a problem to not go ahead. I receive over 300 > spam a day and am doing okay. Most people probably don't have the > technology required to deal with that level of spam, but many do - > they can place their hcards on their website in any form, and > everyone will benefit from that - both the website owners, and the > people who communicate with them. > > And the fact that employing anti-spam technology allows you to > place your hcard in the open, will entice more people to employ > anti-spam measures. > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From scott at randomchaos.com Mon Mar 26 07:40:28 2007 From: scott at randomchaos.com (Scott Reynen) Date: Mon Mar 26 07:40:52 2007 Subject: [uf-discuss] An idea for an application In-Reply-To: <706B7E17-E915-4EE4-B7F9-AA2A4DDB5683@yasuhisa.com> References: <4605B9E6.1080108@proionta.gr> <42059.151.202.81.65.1174786400.squirrel@webmail.nomadcode.com> <4605E887.6050104@proionta.gr> <706B7E17-E915-4EE4-B7F9-AA2A4DDB5683@yasuhisa.com> Message-ID: <7D2FD877-2722-4F39-81C3-7ED5853F1BAB@randomchaos.com> On Mar 26, 2007, at 10:01 AM, Yasuhisa Hasegawa wrote: > Plugin can be interesting implementation. I also would like to > see in desktop app. > I put up some ideas on Flickr a while ago. It's not exactly > what you're talking about, but somewhat similar. > http://www.flickr.com/photos/yhassy/sets/72157594321694651/ The idea of an auto-updating address book has been floating around for a long time, and I hope we'll eventually see several implementations. Here's another recent mention of the same idea: http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/knowee Peace, Scott From jcraig at apple.com Tue Mar 13 18:56:27 2007 From: jcraig at apple.com (James Craig) Date: Mon Mar 26 09:19:49 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <45F5A81A.1010306@xtra.co.nz> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> <009701c76448$af3382c0$bc08a8c0@nzto22> <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> <45F5A81A.1010306@xtra.co.nz> Message-ID: <92D00B61-4E6C-4387-8558-4AC8E27E3BC8@apple.com> Paul Wilkins wrote: >> This is a misuse of abbr at best. >> >> See: open issue! 2007-01-26 >> http://microformats.org/wiki/hcard-issues > > I also see that you are the author of that open issue, and that > it's been rejected. Look again. The original rejection was for a different issue. The real issue is open and valid. James From jcraig at apple.com Mon Mar 26 11:30:47 2007 From: jcraig at apple.com (James Craig) Date: Mon Mar 26 11:30:49 2007 Subject: [uf-discuss] An Inconvenient hCard In-Reply-To: <92D00B61-4E6C-4387-8558-4AC8E27E3BC8@apple.com> References: <923a87360703111806r3ca727dbu39a934f3b62ef850@mail.gmail.com> <008501c76445$93f97a30$bc08a8c0@nzto22> <923a87360703111837j737098e6k435b0ccace026f9b@mail.gmail.com> <009701c76448$af3382c0$bc08a8c0@nzto22> <05D43D42-3757-4F7B-9ECF-DDCA3F10AFEB@apple.com> <45F5A81A.1010306@xtra.co.nz> <92D00B61-4E6C-4387-8558-4AC8E27E3BC8@apple.com> Message-ID: On Mar 13, 2007, at 7:56 PM, James Craig wrote: > Look again. The original rejection was for a different issue. The > real issue is open and valid. Sorry, I sent this two weeks ago but must've been offline until this morning. I've been out of the country and am just now catching up on the threads. James From jcraig at apple.com Mon Mar 26 11:39:32 2007 From: jcraig at apple.com (James Craig) Date: Mon Mar 26 11:39:34 2007 Subject: using class to store type value (was Re: [uf-discuss] An Inconvenient hCard) In-Reply-To: References: Message-ID: <3A4808F7-42A0-4606-88BD-93300B9496E0@apple.com> Tantek ?elik wrote: > Andy Mabbett wrote: > >> A further thought - this wouldn't be an issue, if we had separate >> classes, rather than one class and several types, thus: >> >> (514) 555-4561 >> (514) 555-4562 >> (514) 555-4563 >> (514) 555-4564 > > This was actually initially attempted and rejected because it > constituted > storage of content in the class attribute, which is an anti-design- > pattern. > The "type" in this case is essentially a "tag" on the phone number, > which is > human readable content. > > The resolution is not in an easily discoverable place unfortunately: > http://microformats.org/wiki/hcard-parsing#ISSUE_2 The resoluion still doesn't address the issue of localization (Sorry... "-sation") which is what Andy's potential solution is trying to address. One problem I do see with this solution however, is ambiguity for values like "home" on "tel" and "adr" which would be better suited by the class combinations "tel home", "adr home", etc. That class combination idea was also "attempted and rejected," in my humble opinion, prematurely. James From mdagn at spraci.com Mon Mar 26 19:22:48 2007 From: mdagn at spraci.com (Michael MD) Date: Mon Mar 26 19:22:58 2007 Subject: [uf-discuss] An idea for an application References: <4605B9E6.1080108@proionta.gr><42059.151.202.81.65.1174786400.squirrel@webmail.nomadcode.com><4605E887.6050104@proionta.gr> <706B7E17-E915-4EE4-B7F9-AA2A4DDB5683@yasuhisa.com> Message-ID: <005301c7701f$359bf9a0$116bacca@COMCEN> >>> >>> One problem here is that many people may be unwilling to publish their >>> email addresses on a web page, because of the certainty that the >>> address >>> will be picked up by spammers. This may limit the number of cases where >>> this would be useful. >> >> I can't see that as a problem to not go ahead. I receive over 300 spam a >> day and am doing okay. Most people probably don't have the technology >> required to deal with that level of spam, but many do - they can place >> their hcards on their website in any form, and everyone will benefit >> from that - both the website owners, and the people who communicate with >> them. >> >> And the fact that employing anti-spam technology allows you to place >> your hcard in the open, will entice more people to employ anti-spam >> measures. I think it might be good to have an optional way to publish a link to a contact form to send a message instead of an email address.. (seperately to their website url and somehow saying that it's a contact form) A lot of people would be far less reluctant to publish those. From john at westciv.com Mon Mar 26 21:15:50 2007 From: john at westciv.com (John Allsopp) Date: Mon Mar 26 21:16:08 2007 Subject: [uf-discuss] Microformats Book for Friends of Ed released today In-Reply-To: <96468F7A-4661-4A24-A26F-CDDCED8C9856@westciv.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> <0D364A3B-6319-4538-BAF9-75A8F96067B1@westciv.com> <8E2DF2C8-6935-499F-9561-75C46EF7AF77@allinthehead.com> <96468F7A-4661-4A24-A26F-CDDCED8C9856@westciv.com> Message-ID: <3172F868-8C64-482C-A828-51B9BE6000A9@westciv.com> I hope it might be of interest to members of the community that Microformats - empowering your markup for Web 2.0 is published today by Friends of Ed. http://www.friendsofed.com/book.html?isbn=1590598148 http://microformatique.com/book/ As far as I am aware, its the first complete book dedicated to Microformats on dead trees. Thanks in particular to Brian Suda, the tech editor, and Dan Cederholm and Nate Koechley for the case studies, and of course above all to all those who have contributed to making microformats what they are. I hope the book might play its own little part in furthering the interest in and use of microformats, john John Allsopp style master :: css editor :: http://westciv.com/style_master about me :: http://johnfallsopp.com Web Directions Conferences :: http://webdirections.org My Microformats book :: http://microformatique.com/book From scott at randomchaos.com Tue Mar 27 06:18:59 2007 From: scott at randomchaos.com (Scott Reynen) Date: Tue Mar 27 06:19:10 2007 Subject: [uf-discuss] An idea for an application In-Reply-To: <005301c7701f$359bf9a0$116bacca@COMCEN> References: <4605B9E6.1080108@proionta.gr><42059.151.202.81.65.1174786400.squirrel@webmail.nomadcode.com><4605E887.6050104@proionta.gr> <706B7E17-E915-4EE4-B7F9-AA2A4DDB5683@yasuhisa.com> <005301c7701f$359bf9a0$116bacca@COMCEN> Message-ID: <2BE8E0FA-01E9-4328-88B0-6172D75BF2AA@randomchaos.com> On Mar 26, 2007, at 10:22 PM, Michael MD wrote: > I think it might be good to have an optional way to publish a link > to a contact form to send a message instead of an email address.. > (seperately to their website url and somehow saying that it's a > contact form) > A lot of people would be far less reluctant to publish those. Putting aside the controversial subject of favorite spam fighting techniques for a moment, what exactly would a consuming application do with contact URLs apart from what they already do with hCard URLs in general? Peace, Scott From andy at pigsonthewing.org.uk Tue Mar 27 15:00:59 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Mar 27 15:02:12 2007 Subject: [uf-discuss] Geo advocacy successes Message-ID: Those of you not following changes on the Wiki might like to know that I've had some successes, as part of our "advocacy" drive: in getting sites to add "Geo" to their mark-up. * POI66 added it to over 58,500, in under 4 hours from initial contact! POI66 publishes lists of Points-Of-Interest, such as camp sites, museums or bars; and Trails, which can be used for trips, such as hikes and sailing routes (and which are likely candidates for a future geo-sequencing extension). They're also looking at hCard. * Geograph British Isles marked-up over *370,000* examples, within *30 minutes* of my request being submitted! This project aims to collect geographically representative photographs and information for every square kilometre of the UK and the Republic of Ireland. and there's a new implementation: * AddressFix will now take and valid US postal address converted, within one day of request being submitted. They'll do other countries, as and when Google adds the functionality. In each case, I e-mailed a short paragraph about the relevant microformats, links to the 'wiki', and a sample of their mark up, with and without microformats added. If we all (and, yes, that includes you) send just one e-mail a week, to a likely site, just think how much more quickly microformats will spread. -- Andy Mabbett From tantek at cs.stanford.edu Wed Mar 28 00:29:49 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Wed Mar 28 00:29:39 2007 Subject: [uf-discuss] Geo advocacy successes In-Reply-To: Message-ID: On 3/27/07 4:00 PM, "Andy Mabbett" wrote: > > Those of you not following changes on the Wiki might like to know that > I've had some successes, as part of our "advocacy" drive: > > Andy, congratulations on your advocacy successes! > In each case, I e-mailed a short paragraph about the relevant > microformats, links to the 'wiki', and a sample of their mark up, with > and without microformats added. > > If we all (and, yes, that includes you) send just one e-mail a week, to > a likely site, just think how much more quickly microformats will > spread. I also want to congratulate both your positive attitude and focus here and encourage you to share representative samples of the emails you have sent that have resulted in successes to make it just that much easier for the rest of the community to follow your suggestion and example of sending just one email a week to likely sites. http://microformats.org/wiki/advocacy-email-samples I have a added a couple of sample emails to begin with that have resulted in success in the past for me. Thanks, Tantek From andy at pigsonthewing.org.uk Wed Mar 28 01:50:44 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 28 01:54:21 2007 Subject: [uf-discuss] Geo advocacy successes In-Reply-To: References: Message-ID: In message , Andy Mabbett writes > * AddressFix will now take and valid > US postal address converted, within one day of request being > submitted. They'll do other countries, as and when Google adds > the functionality. Not just US Addresses: * Countries: Andorra, Australia, Austria, Belgium, Canada, France, Germany, Gibraltar, Italy, Japan (but only in Japanese), Liechtenstein, Luxembourg, Monaco, Netherlands, New Zealand, San Marino, Spain, Sweden, Switzerland, United States of America and the Vatican City. * For countries other than the UK, the British Isles and China it provides geocoding for country names and city names (e.g. "Nairobi, Kenya"). * For UK, the British Isles and China an error is returned by Google :-( (correct as of time of posting) -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Mar 28 01:59:42 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 28 02:09:36 2007 Subject: [uf-discuss] Licensing of "button" images Message-ID: <6jIURa$OyjCGFwHB@pigsonthewing.org.uk> Will the contributors who kindly provided the "button" icons on: please indicate on that page, that those images are either in the public domain or available under a specified free license, as per the new section: Thank you. -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Mar 28 02:24:26 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 28 02:35:26 2007 Subject: [uf-discuss] Geo advocacy successes In-Reply-To: References: Message-ID: <0rtXDPAaJkCGFwXj@pigsonthewing.org.uk> In message , Tantek ?elik writes >share representative samples of the emails you have sent that have >resulted in successes to make it just that much easier for the rest of >the community to follow your suggestion and example of sending just one >email a week to likely sites. > >http://microformats.org/wiki/advocacy-email-samples Done. One a week was a minima, of course! It's also important that people list the sites they've contacted, on the advocacy page: so that we don't end up "spamming" (as they would se ti) the same one. Also, if people have contacts in the larger, effectively uncontactable organisations (Google IMDb, large multinationals, etc.) the should, if appropriate, make use of them. -- Andy Mabbett From hsivonen at iki.fi Wed Mar 28 08:47:11 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Wed Mar 28 08:47:12 2007 Subject: hCard creator and multitoken given/family names (was: Re: [uf-discuss] hCite elevator pitch and my bibliography generator) In-Reply-To: <4603C690.5010305@xtra.co.nz> References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> <4603C690.5010305@xtra.co.nz> Message-ID: <138A9A2F-0A0C-4F31-8278-3FD5927EF077@iki.fi> On Mar 23, 2007, at 14:22, Paul Wilkins wrote: > Currently the formatted names are accepted in the following formats > > given-name (space) family-name > family-name (comma) given-name > family-name (comma) given-name-first-initial > family-name (space) given-name-first-initial (optional period) Then it appears that hCard creator (http://microformats.org/code/ hcard/creator) is broken. If I enter "Jesus Maria" as the given name and "van der Boer y Gonzales" as the family name, I get: Jesus Maria van der Boer y Gonzales I'd be interested in a design rationale pointer explaining why having more than two tokens in an fn is not allowed when the information about the roles of the tokens is unavailable to the producer of the markup. Is this something that has been inherited wholesale from vCard? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From ryan at technorati.com Wed Mar 28 10:00:00 2007 From: ryan at technorati.com (Ryan King) Date: Wed Mar 28 10:00:09 2007 Subject: hCard creator and multitoken given/family names (was: Re: [uf-discuss] hCite elevator pitch and my bibliography generator) In-Reply-To: <138A9A2F-0A0C-4F31-8278-3FD5927EF077@iki.fi> References: <45F31ED3.90500@xtra.co.nz> <8650F2A3-36E8-49C1-BFA3-60DBA9E03AD2@iki.fi> <4603C690.5010305@xtra.co.nz> <138A9A2F-0A0C-4F31-8278-3FD5927EF077@iki.fi> Message-ID: <9F9F805D-4396-4EE6-944B-E8E09CAC957E@technorati.com> On Mar 28, 2007, at 9:47 AM, Henri Sivonen wrote: > On Mar 23, 2007, at 14:22, Paul Wilkins wrote: > >> Currently the formatted names are accepted in the following formats >> >> given-name (space) family-name >> family-name (comma) given-name >> family-name (comma) given-name-first-initial >> family-name (space) given-name-first-initial (optional period) > > Then it appears that hCard creator (http://microformats.org/code/ > hcard/creator) is broken. > > If I enter "Jesus Maria" as the given name and "van der Boer y > Gonzales" as the family name, I get: > Jesus Maria van der Boer y Gonzales This is a bug caused by lack of foresight on my part. It should be fixed now. > I'd be interested in a design rationale pointer explaining why > having more than two tokens in an fn is not allowed when the > information about the roles of the tokens is unavailable to the > producer of the markup. Is this something that has been inherited > wholesale from vCard? Having more than 2 tokens in an fn is allowed, it's just not useful for calculating an implied-n. -ryan -- Ryan King ryan@technorati.com From jason at sixtwothree.org Wed Mar 28 10:58:40 2007 From: jason at sixtwothree.org (Jason Garber) Date: Wed Mar 28 10:58:45 2007 Subject: [uf-discuss] Geo advocacy successes In-Reply-To: <0rtXDPAaJkCGFwXj@pigsonthewing.org.uk> References: <0rtXDPAaJkCGFwXj@pigsonthewing.org.uk> Message-ID: <460ABAE0.6030002@sixtwothree.org> Andy Mabbett wrote: > Also, if people have contacts in the larger, effectively uncontactable > organisations (Google IMDb, large multinationals, etc.) the should, if > appropriate, make use of them There's a growing number of folks within AOL who are hip to microformats and with people like myself, Kevin Lawver, and others, we're raising awareness and evangelizing for The Cause. I've got my hands in a few projects and you can be there'll be microformats in each of them (Ficlets being the first). Well done, Andy, it's good to see the work you've done in converting the masses. Jason jason@sixtwothree.org From michael.mccracken at gmail.com Thu Mar 29 10:59:55 2007 From: michael.mccracken at gmail.com (Michael McCracken) Date: Thu Mar 29 10:59:58 2007 Subject: [uf-discuss] [hcite] date-published In-Reply-To: <919096.40349.qm@web30808.mail.mud.yahoo.com> References: <919096.40349.qm@web30808.mail.mud.yahoo.com> Message-ID: 2007/2/21, Tim White : > Jeremy said: > >Though not really arguing > >against Tim's reasons, there are cases in which citations can have a > >date published and a date visited or accessed. > > > Most definitely. I did not mean to discount the value of date-accessed. > > > > >That said, should there also be a date-accessed or date-visited value > > > >for hCite? > > > I believe date-access is in the staw schema... yup, it's there. > http://microformats.org/wiki/citation-brainstorming#Basic_Citation_Stuctures > > > ~ Tim > OK, I disappeared for a while there, but is it fair to summarize this thread by saying that the two field names we have the best evidence for in terms of usage on the actual web are 'date-published' and 'date-accessed'? I've had my mind changed about my earlier position that using 'date' would be better than 'date-published'. Vagueness of the data aside, the majority of our examples show at least an intent of describing a publication date, and I think we don't gain anything by making our field name less specific. Therefore, the schema will stay as-is on the wiki at http://microformats.org/wiki/citation-brainstorming#Working_straw_schema Comments? -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ From andy at pigsonthewing.org.uk Thu Mar 29 11:23:17 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Mar 29 11:24:26 2007 Subject: [uf-discuss] [hcite] date-published In-Reply-To: References: <919096.40349.qm@web30808.mail.mud.yahoo.com> Message-ID: <02jHkIglIBDGFwux@pigsonthewing.org.uk> In message , Michael McCracken writes >OK, I disappeared for a while there, but is it fair to summarize this thread >by saying that the two field names we have the best evidence for in terms of >usage on the actual web are 'date-published' and 'date-accessed'? I've been reading Wikipedia's articles and policies on citation, and it uses both; -published chiefly for books and journal articles; -accessed for citing external web pages. (Start at: ) -- Andy Mabbett I wonder what the archives, Google Groups et al will make of: 52.483- 1.893 From michael.mccracken at gmail.com Thu Mar 29 11:41:01 2007 From: michael.mccracken at gmail.com (Michael McCracken) Date: Thu Mar 29 11:41:47 2007 Subject: [uf-discuss] [hcite] nesting container elements In-Reply-To: References: Message-ID: (note - I originally sent this to uf-dev accidentally. My impression is that more hcite people are on uf-discuss. Correct me if I'm wrong and we can move this to uf-dev. Thanks!) We need to deal with bibliographic details for things like chapters in a book, articles in a journal or magazine, and issues in a series. For designing a format, the main problem is that there are duplicate items that need to be scoped - for instance, both the article and the journal have a title. The point has been made in a few places that many existing bibliographic formats handle this by just adding fields at the top level - for example in the common usage of bibtex, a chapter of a book is a record of type "inbook", and the "title" field represents the book title, while the chapter title is recorded in the "chapter" field. For example: @inbook{TAOCP4b, title = {The Art of Computer Programming: Graph and Network Algorithms}, chapter = {Expander Graphs}, ... } While it's certainly possible to continue this scheme of adding field names whenever a publication type can be contained by another type with clashing fields, other formats have adopted an approach that avoids this field name multiplication, at the cost of a little extra complexity in nesting. For example, an article in a journal, represented in MODS XML (from http://www.scripps.edu/~cdputnam/software/bibutils/mods_intro.html ): Different base/base mismatches are corrected with different efficiencies by the methyl-directed DNA mismatch-repair system of E. coli ... Cell ... In this way, when a journal has a title, you just use the 'title' field, and you don't need to remember the difference between 'booktitle', 'chapter', 'journal', etc... There's also the advantage that you can support more types of references without changing the format to add new field names. I am proposing that we treat these cases in hCite in a way similar to MODS instead of the way BibTeX does it. Here's what I propose for hCite: I propose a 'container' class name that would be attached to a nested hCite instance to note when the nested hCite represents the containing item for the root hCite. The journal example above would then look something like this: Different base/base mismatches are corrected with different efficiencies by the methyl-directed DNA mismatch-repair system of E. coli ... Cell ... Comments? FWIW, I have code in BibDesk that interprets this nesting scheme to translate into BibTeX, and it works pretty well. *note - Yes, it is also useful to know the type of the container so we can tell if we're looking at a book or a journal, but that's a separate discussion we'll have to have soon enough. For now lets focus on the nesting issue. Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ From andy at pigsonthewing.org.uk Fri Mar 30 02:49:00 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 30 02:52:21 2007 Subject: [uf-discuss] Geo deployed on Wikipedia. Message-ID: I've just added: Geo to Wikipedia's GeoTemplate: which is called by *many thousands* of other Wikipedia pages. For example: the coordinates (top right) in: link to: the latter now has a Geo microformat. Work to add Geo to the individual articles is ongoing. -- Andy Mabbett From michael.mccracken at gmail.com Fri Mar 30 09:42:13 2007 From: michael.mccracken at gmail.com (Michael McCracken) Date: Fri Mar 30 09:42:17 2007 Subject: [uf-discuss] Re: [hcite] nesting container elements In-Reply-To: References: Message-ID: I've added an example for a journal article to the wiki: http://microformats.org/wiki/citation-brainstorming#Citing_a_journal_article -mike 2007/3/29, Michael McCracken : > (note - I originally sent this to uf-dev accidentally. My impression > is that more hcite people are on uf-discuss. Correct me if I'm wrong > and we can move this to uf-dev. Thanks!) > > We need to deal with bibliographic details for things like chapters in > a book, articles in a journal or magazine, and issues in a series. > > For designing a format, the main problem is that there are duplicate > items that need to be scoped - for instance, both the article and the > journal have a title. > > The point has been made in a few places that many existing > bibliographic formats handle this by just adding fields at the top > level - for example in the common usage of bibtex, a chapter of a book > is a record of type "inbook", and the "title" field represents the > book title, while the chapter title is recorded in the "chapter" > field. For example: > > @inbook{TAOCP4b, > title = {The Art of Computer Programming: Graph and Network Algorithms}, > chapter = {Expander Graphs}, > ... > } > > While it's certainly possible to continue this scheme of adding field > names whenever a publication type can be contained by another type > with clashing fields, other formats have adopted an approach that > avoids this field name multiplication, at the cost of a little extra > complexity in nesting. For example, an article in a journal, > represented in MODS XML (from > http://www.scripps.edu/~cdputnam/software/bibutils/mods_intro.html ): > > > > Different base/base mismatches are corrected with > different efficiencies by the methyl-directed DNA mismatch-repair > system of E. coli > > ... > > > Cell > > ... > > > > In this way, when a journal has a title, you just use the 'title' > field, and you don't need to remember the difference between > 'booktitle', 'chapter', 'journal', etc... There's also the advantage > that you can support more types of references without changing the > format to add new field names. > > I am proposing that we treat these cases in hCite in a way similar to > MODS instead of the way BibTeX does it. Here's what I propose for > hCite: > > I propose a 'container' class name that would be attached to a nested > hCite instance to note when the nested hCite represents the containing > item for the root hCite. The journal example above would then look > something like this: > > > Different base/base mismatches are corrected with > different efficiencies by the methyl-directed DNA mismatch-repair > system of E. coli > > ... > > Cell > ... > > > > Comments? > > FWIW, I have code in BibDesk that interprets this nesting scheme to > translate into BibTeX, and it works pretty well. > > *note - Yes, it is also useful to know the type of the container so we > can tell if we're looking at a book or a journal, but that's a > separate discussion we'll have to have soon enough. For now lets focus > on the nesting issue. > > Thanks, > -mike > > -- > Michael McCracken > UCSD CSE PhD Candidate > research: http://www.cse.ucsd.edu/~mmccrack/ > misc: http://michael-mccracken.net/wp/ > -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ From scott at randomchaos.com Fri Mar 30 10:10:11 2007 From: scott at randomchaos.com (Scott Reynen) Date: Fri Mar 30 10:10:23 2007 Subject: [uf-discuss] [hcite] nesting container elements In-Reply-To: References: Message-ID: <87BEDAB4-D920-494D-9F1E-110A9C9E5444@randomchaos.com> On Mar 29, 2007, at 2:41 PM, Michael McCracken wrote: > I propose a 'container' class name that would be attached to a nested > hCite instance to note when the nested hCite represents the containing > item for the root hCite. The journal example above would then look > something like this: > > > Different base/base mismatches are corrected > with > different efficiencies by the methyl-directed DNA mismatch- > repair > system of E. coli > > ... > > Cell > ... > > > > Comments? Maybe this has already been covered and I missed it, but why wouldn't we use HTML nesting to indicate citation nesting? That is, rather than specify which node is a container with a class name, do it by actually having it contain the relevant nodes, e.g. (and I'm proposing this as actual markup, just how nesting could work):

Different base/base mismatches are corrected with different efficiencies by the methyl-directed DNA mismatch- repair system of E. coli

...
Cell

That would require parsers to know all potential sub-types of each media type so an article title wouldn't get misinterpreted as a journal title, but that looks to me like a relatively small burden for parsers in exchange for simpler publishing. Peace, Scott From scott at randomchaos.com Fri Mar 30 10:28:54 2007 From: scott at randomchaos.com (Scott Reynen) Date: Fri Mar 30 10:29:00 2007 Subject: [uf-discuss] [hcite] nesting container elements In-Reply-To: <87BEDAB4-D920-494D-9F1E-110A9C9E5444@randomchaos.com> References: <87BEDAB4-D920-494D-9F1E-110A9C9E5444@randomchaos.com> Message-ID: <8BB3B785-9EA1-4E74-B4F6-DDFB98F32CFB@randomchaos.com> On Mar 30, 2007, at 1:10 PM, Scott Reynen wrote: > That is, rather than specify which node is a container with a class > name, do it by actually having it contain the relevant nodes, e.g. > (and I'm proposing this as actual markup, just how nesting could > work): Oops, I meant to say I'm *not* proposing this as actual markup. Peace, Scott From michael.mccracken at gmail.com Fri Mar 30 11:33:17 2007 From: michael.mccracken at gmail.com (Michael McCracken) Date: Fri Mar 30 11:33:28 2007 Subject: [uf-discuss] [hcite] nesting container elements In-Reply-To: <87BEDAB4-D920-494D-9F1E-110A9C9E5444@randomchaos.com> References: <87BEDAB4-D920-494D-9F1E-110A9C9E5444@randomchaos.com> Message-ID: 2007/3/30, Scott Reynen : > On Mar 29, 2007, at 2:41 PM, Michael McCracken wrote: > > > I propose a 'container' class name that would be attached to a nested > > hCite instance to note when the nested hCite represents the containing > > item for the root hCite. The journal example above would then look > > something like this: > > > > > > Different base/base mismatches are corrected > > with > > different efficiencies by the methyl-directed DNA mismatch- > > repair > > system of E. coli > > > > ... > > > > Cell > > ... > > > > > > > > Comments? > > Maybe this has already been covered and I missed it, Not that I know of. > but why wouldn't > we use HTML nesting to indicate citation nesting? That is, rather > than specify which node is a container with a class name, do it by > actually having it contain the relevant nodes, e.g. (and I'm not > proposing this as actual markup, just how nesting could work): > >
>
>
Different base/base mismatches are corrected > with different efficiencies by the methyl-directed DNA mismatch- > repair system of E. coli
>
> ... >
Cell
>
one concern about nesting like this is that common citation formatting actually nests information about the container inside info about the contained item. For example, see the journal name in this citation: Klapper PE, Cleator GM, Dennett C, Lewis AG (1990) Diagnosis of herpes encephalitis via Southern blotting of CSF DNA amplified by polymerase chain reaction. J Med Virol 32:261-264 So, in this case we have container info ("J Med Virol") completely surrounded by contained-item info (authors, year, title before, then pages after). I'm not sure this is always the case, but it does point out a problem in using the nested-hcite element approach, whichever way the nesting is interpreted. > That would require parsers to know all potential sub-types of each > media type so an article title wouldn't get misinterpreted as a > journal title, Can you expand on this point a bit? I'm not really seeing why that'd be necessary. Wouldn't it be enough just to say that children of an hCite that are also children of a child hCite don't apply to the parent hCite? >but that looks to me like a relatively small burden > for parsers in exchange for simpler publishing. -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ From john at proionta.gr Sat Mar 31 17:50:16 2007 From: john at proionta.gr (John) Date: Sat Mar 31 17:50:22 2007 Subject: [uf-discuss] Proposal: wishlist microformat Message-ID: <460F0FD8.8080407@proionta.gr> Similar to the Amazon wishlist, a user would be able to list things that he wants using this microformat. Can be also thought of as an opposite to hlisting. What do the microformats list members think?

March 6th, 2007 at The Black Sheep

Valient Thorr at 8:00 pm

Fu Manchu at 8:30 pm

March 6th, 2007 at The Black Sheep

Valient Thorr at 8:00 pm

Fu Manchu at 8:30 pm

Different base/base mismatches are corrected with different efficiencies by the methyl-directed DNA mismatch- repair system of E. coli

Cell

Different base/base mismatches are corrected > with different efficiencies by the methyl-directed DNA mismatch- > repair system of E. coli

Cell