Re: [uf-discuss] Microformats for Write APIs
Thom Shannon wrote: Standardisation might be interesting here as well. For instance back to blog comments. Comments from within aggregators would likely be simpler where comment form definitions can be established programmatically. The problem is that comment spammers would love that too! You could always add some standards for including captchas (both visual and auditory) and also include form auth tokens (used to stop cross site posting attacks) which would be tricky to implement considering the way this functionality would be used. There's OpenID to consider too. Keeping comments from fragmenting is a worthwhile goal. Large hosted blog site already have this problem of being targets for comment spammers, and use the countermeasures above as well as others, so perhaps they'd be interested in standardizing this. OAuth could help with cross site posting, though it would require a trip through the target site's UI. (Disclosure: I work on Blogger.) John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar, geo Operator extension
Paul Wilkins wrote: On Dec 4, 2007 10:26 AM, Ben Ward [EMAIL PROTECTED] wrote: The critical part of the HTML4 spec that causes 'Rayenda, Bangladesh' *not* to be an abbreviation of '22.31119;+89.86145' is this: The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. as it would normally appear in running text. For the ABBR element to be use properly the title attribute would need to contain not a single point coordinate, but a representation of the Rayenda area itself. While this could be done by combining the techniques for image map poly coordinates with actual geo-coordinates, this needs to be more carefully and fully thought out. I've been asked how to handle this case (you have an area, or an inexact location, and want to encode it while providing a friendly human readable but possibly ambiguous short hand name for said place). Is there any existing practices to look at? Secondly, would this be a valid geo encoding 'abbreviation' ? abbr title='22.31119;+89.86145'the point under my finger right now/abbr John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Blogger now supports hAtom
Conor O'Neill wrote: Just spotted on Blogger Dev Group that Blogger now supports hAtom. Congrats to whoever evangelised this into Google and to Pete Hopkins and the crew in there. http://groups.google.com/group/bloggerDev/browse_thread/thread/69344c5cc35b472e?hl=en Thanks. Kevin Marks deserves a lot of the credit for evangelizing :). -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
Chris Messina wrote: ... I created a simple XFN aggregating application, it occurs to me that adding email addresses, both for the purpose of rel-me links and for contact links is actually useful and something that should be supported in XFN (it's currently not clear whether this is acceptable or not; I'm making the case that it should be). Therefore, this: a href=mailto:[EMAIL PROTECTED] rel=contactBuddy/a should be as acceptable as this: a href=http://foo.com/buddy; rel=contactBuddy/a And, on http://foo.com/buddy, this should be permissible: a href=mailto:[EMAIL PROTECTED] rel=meBuddy/a Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. In principle it seems no worse to me than the aim: links currently recommended in the hCard spec. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-edit
Evan Prodromou wrote: ... I think this microformat would be best defined using the semantics of the rel attribute of a links. For example, on the how-to-play page on the microformats wiki, this link: a href=/wiki?title=how-to-playamp;action=editEdit/a would be changed to: a href=/wiki?title=how-to-playamp;action=edit rel=editEdit/a I'd like to start a draft rel-edit page on microformats.org; but first I'd like to gather some feedback on this mailing list. Just FYI: The Atom Publishing Protocol draft spec uses link rel=edit .../ to point from a read-only representation of a resource to an alternative URI that allows for editing operations, and in particular one which is supposed to support loss-less GET/edit locally/PUT semantics in the case of Atom resources. -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenID
Arve Bersvendsen wrote: On Tue, 20 Feb 2007 22:24:00 +0100, Thom Shannon [EMAIL PROTECTED] wrote: Forgive me if this is going over old ground, I just joined this list and couldn't find what I was looking for on the wiki. Are there any particular conventions emerging for embedding an OpenID into a hCard? The openid-brainstorming page mentions using hCard on providers profile pages etc, but I was thinking there should be a way to have your OpenID on other profiles that can easily be consumed, allowing someone to see you on social network A and add you on their social network B based on you using the same OpenID. I'm guessing it would be as simple as a class=url fn openid href=http://ts0.com;? Just wanted to know what others are doing. I would think that using a rel value would make more sense, since rel exists to signify the relationship between the current document (or context therein); a href=http://example.com/; rel=openid.identifierMy OpenID/a The UID seems to be limited to the hcard itself, while the rel's context is larger; is there a way to tell what context is meant? I just realized that I typed rel=url uid earlier rather than class=url uid. :( -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenID
Thom Shannon wrote: Hi, Forgive me if this is going over old ground, I just joined this list and couldn't find what I was looking for on the wiki. Are there any particular conventions emerging for embedding an OpenID into a hCard? The openid-brainstorming page mentions using hCard on providers profile pages etc, but I was thinking there should be a way to have your OpenID on other profiles that can easily be consumed, allowing someone to see you on social network A and add you on their social network B based on you using the same OpenID. I'm guessing it would be as simple as a class=url fn openid href=http://ts0.com;? Just wanted to know what others are doing. I actually have the same question. At the moment we're doing this: span class=vcarda class=fn urlhref=http://journals.aol.com/panzerjohn; target=_blankpanzerjohn/a/span where http://journals.aol.com/panzerjohn is an OpenID URL (or will be shortly). A live example is at http://beta.journals.aol.com/panzerjohn/abstractioneer. I had been thinking it might be useful to be explicit about the fact that the target is not just a url, but also an openid. If people think that's a good idea I can add it in to our code. -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenID
Scott Reynen wrote: On Feb 20, 2007, at 3:24 PM, Thom Shannon wrote: Forgive me if this is going over old ground, I just joined this list and couldn't find what I was looking for on the wiki. Are there any particular conventions emerging for embedding an OpenID into a hCard? The openid-brainstorming page mentions using hCard on providers profile pages etc, but I was thinking there should be a way to have your OpenID on other profiles that can easily be consumed, allowing someone to see you on social network A and add you on their social network B based on you using the same OpenID. I'm guessing it would be as simple as a class=url fn openid href=http://ts0.com;? Just wanted to know what others are doing. I think that looks a lot like what Ryan King recently suggested for UID+URL. It's not in the wiki yet, but you should be able to find it by searching the email archives for UID+URL. Is UID intended to be more general than indicating more authoritative hCard? Or do you mean that the overall concept is similar, not necessarily that rel=uid url is a solution? I'm thinking here of cases where the target may be an OpenID, but not necessarily provide an hCard. An example of this might be href=xri://=john.panzer[1]. -John [1] See http://www.equalsdrummond.name/?p=39 for analogous usages. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Cross-network identification (Was: OpenID)
Scott Reynen wrote: On Feb 20, 2007, at 6:56 PM, John Panzer wrote: Scott Reynen wrote: ... Here's the purpose of UID from vCard: To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard. So if two hCards have the same UID, they must refer to the same person, because otherwise it wouldn't be globally unique. And I think that solves the problem Thom described above, unless I'm missing why it needs to be specific to OpenID. Nope, it solves it. OpenID URLs are just one example. ... I'm thinking here of cases where the target may be an OpenID, but not necessarily provide an hCard. UIDs do not need to point to hCards. Nor do they need to be OpenIDs. They can do both, but the only requirement is that they be globally unique and correspond to the subject of the hCard. And that minimal requirement seems to be just enough to solve this problem without worrying about what, if anything, is on the other end of the UID. Thanks. (The thread in the archives was somewhat twisty; the summary is helpful.) So, rel=url uid it is. I think this solves the problem of how to match one hCard up with another using a convenient unique key well above the 80% level. One minor point: URLs are unique but not truly persistent. Due to URL reuse,when trawling through archives you can't assume that UID1 == UID2 means person 1 == person 2 unless both UIDs were minted at the same time. I'd probably solve this heuristically if ever necessary, but: Is it worth an implementor's warning somewhere? Interestingly, the vcard people seemingly dealt with this issue, because they edited [1] persistent, globally unique identifier prior to the final RFC draft. -John Panzer [1] http://www.imc.org/pdi/vcard-21.txt ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Use of xoxo+hCard for group membership lists
All, We have deployed an output format using xoxo+hCard for a type of group membership lists. It's behind HTTP Basic access control but it'd be interesting to see if there are any tools which can get to it, or in-browser tools such as Greasemonkey which can do interesting things with the data. Any pointers? Here's a sample link: https://beta.journals.aol.com/_atom/list/atomprotocol/testprivate/readers (user: atomprotocol, password: password) and here's sample output: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; head meta http-equiv=content-type content=text/html; charset=utf-8 / titleReaders/title /head body ol id='readers' class='xoxo' li class='vcard'a class='fn url' href='aim:goim?screenname=chattingchuck'chattingchuck/a/li li class='vcard'a class='fn url' href='aim:goim?screenname=panzerjohn'panzerjohn/a/li /ol /body /html The use case for this is to let a user keep track of parts of their social network, and specifically the parts that in this case are allowed access to their blog. Comments are welcomed. -- John Panzer System Architect http://abstractioneer.org ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Nested hCards (WAS: microformats for groups and group memberships?)
In our blogging app, we currently use a xoxo list of vcards as one format for simple friends lists of readers and contributors. Our use case is a bit more oriented towards personal lists than publishing (think Rolodex or buddy list), but perhaps it maps well to the contact groups/category model. My Friends are a group from my point of view, regardless of whether they actually know each other. Currently we're just using separate xoxo lists for the separate groups or roles. This is a bit annoying as there may be quite a bit of overlap and we'd like to be able to have a flexible representation that can easily 'compactify' this information. Categories sound like the right tool for this job; are they? A concrete example: ul class=xoxo li class=vcard a href=aim:goim?ChattingChuck class=fn urlChuck/a (span class=categoryreader/span) li class=vcard a href=aim:goim?SurfinDave class=fn urlDave/a (span class=categoryreader/span, span class=categorycontributor/span) /li /ul So Chuck is categorized as a reader, while Dave is categorized as both a reader and contributor. (If this seems too special-case, think Friend and Colleague categories in an address book. Is this reasonable? -John brian suda wrote: Correct, when you export out of some address books you will notice that the Groups come across as Categories. You could easily do something like: div class=vcard ... a href=http://acm.org; rel=member class=categoryACM/a ... /div -brian Chris Messina wrote: So in rethinking my proposal, I can't think of any client software that allows nested vcards. In my example, I basically wanted a group to be able to have members. Thinking it over though, Address Book.app allows groups of contacts and will also export those groups (need to see their syntax). Perhaps my proposal was wrong, but this issue of scoping helps show why. I think this fact -- that client software does support grouping -- should give us extra impetus to push ahead with our brainstorming. Chris On 8/14/06, Brian Suda [EMAIL PROTECTED] wrote: This mark-up snippit came across the mailing list a few days ago, i just wanted to point out a few parsing issues that people MIGHT not have been aware of. There's no reason why you couldn't do this and infer a relationship: div class=vcard h2 class=fn orgFoo Co./h2 h3Member Listing/h3 ul class=xoxo li class=vcarda href=http://mulettesgalore.com; class=fn url rev=founder moderator memberJoe Bob/a/li /ul /div In this example there is an hCard inside another hCard. The deapest class=vcard (the second instance) will pull the following fields: FN: Joe Bob URL: http://mulettesgalore.com This is expected and makes sense. The outermost hCard (the first instance) will probably pull more than expected. FN: Foo Co. ORG: Foo Co. URL: http://mulettesgalore.com Because a parse finds the FIRST class=vcard it will then attempt to look at ANY child element for additional properties. It finds the first FN and ORG == to Foo Co. and uses that - it will also find Joe Bob but because it will ONLY take the first instance, we are safe here - so ORDER DOES MATTER!!! It will then continue to look through the list of properies and it will find that URL does match the criteria and also pull that. We all sort of assume that the URL is part of Joe Bob's vCard, but according to the parsing rules Foo Co. will find this. This is not a bug, it is a feature. When we begin to nest hCards in hCalendars, they BOTH have a URL property, this is shared so a URL inside a vCard which is inside a vEvent will be pulled for that EVENT, which might not be what is intended. Just wanted to make folks aware that scoping could be a misunderstood issue. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Sanity check on hCard usage
OK, so this span class=fnChattingChuck/span would produce a blank N, but the implied nickname rule would kick in to produce nickname:ChattingChuck? If so, then the remaining question is: Is this useful enough to mark up as an hcard? There's not much you can do with the nickname without more context except display it. brian suda wrote: Actually, the ONLY property that is mandatory is FN (and the root class of vcard). The N property can be extracted from an FN (when possible). So in the example you would need: li class=vcardspan class=fn nicknameChattingChuck/span/li There is also an implied-nickname rule that if a FN is only one word long it is used. So class=nickname is redundant. In this case since there is no explicit N, and since the FN does not meet the implied N rule, the N value in the final output will be N:; (blank) -brian Chris Messina wrote: I think in order to validate, you need to supply at least the 'n' value, even if the screenname is not the actual name: li class=vcardspan class=n nicknameChattingChuck/span/li On the other hand, I don't know if you *should* mark up those fragments as hcards given the 'n' requirement... I think it's good to be semantic to the last drop, but I think Tantek's advice on this issue would help: how little data can substantiate hcard markup? Chris On 5/23/06, John Panzer [EMAIL PROTECTED] wrote: All, I have a use case for displaying lists of people (readers of a blog) which seems reasonable to mark up using XOXO and hCard. However, in at least some of the cases the only piece of information I have about a user is their login ID, which is an AOL/AIM 'screen name'. Is this a reasonable minimal hCard markup for these cases? li class=vcardspan class=nicknameChattingChuck/span/li Two questions here: (1) is nickname the right way to say this and (2) is this sufficient to be a reasonable if minimal hCard? Thanks, John Panzer ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Licensing and microformat content within feeds
At the moment, I'm looking for exactly this -- pointers to existing actual practices. I'll note that the Feedburner approach (http://www.burningdoor.com/eric/archives/000759.html) is different from James Snell's link rel="license" extension for Atom. Is one or the other in actual use? Chris Messina wrote: Feedburner already allows you to embed a license in your feed. We should document their approach. I think feeds already allow you to embed a license generally: http://www-128.ibm.com/developerworks/xml/library/x-extatom2.html http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/ One other idea to consider for hAtom at least would be embedding a license using the object tag -- this way you could simply refer to the external license permalink and not replicate all the extra data (which seems to me one of the shortcomings of the current licensing implementation). http://microformats.org/discuss/mail/microformats-discuss/2006-February/003147.html Anyway, I might be missing the point of your question -- what are you looking for? Chris On 3/22/06, John Panzer [EMAIL PROTECTED] wrote: I'm starting a discussion about feed licencing which might be of interest to members of this mailing list, and which will hopefully help form the technical extensions that AOL adopts to deal with feed licencing issues. I'm soliciting input from the community. This may apply to hAtom (to the extent that hAtom ends up being used as a substitute for XML based feed data) and of course data within RSS or Atom feeds may have RelLicence elements. Link: http://journals.aol.com/panzerjohn/abstractioneer/entries/1281 This is the initial discussion, painfully abstracted to avoid the complicated stuff. I'm trying at this point to see which of these starting assumptions are themselves problematic before going further. Thanks, -- John Panzer System Architect http://journals.aol.com/panzerjohn/abstractioneer ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- John Panzer System Architect, AOL http://abstractioneer.org ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
Angus McIntyre wrote: What's the best course of action in cases like these? My use-case doesn't exactly fit hAtom because it doesn't meet the mandatory 'author' and 'content' requirements. I was under the impression that most of these sorts of requirements are carried over from Atom itself, not things that hAtom invented. For example, the requirements on author as specified in RFC 4287: atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Thus, I suggest you use whatever solution you came up with for generating the actual Atom feeds. Your Atom feeds are valid Atom 1.0, aren't they? :-p Ahem ... cough ... well, yes, actually. Give or take a few non-UTF8 characters that keep creeping in. For the Atom feeds, I seem to have got around the author requirement by using the feed owner as the author of the whole feed. I guess I just have to use that solution and decide where I want to put the author on my pages. For aesthetic reasons, I'd rather not have the author shown on those pages but I think it's counter to the spirit of microformats to write the author block and then hide it using CSS (rendering it machine-readable but human-invisible) so I may just have to bite that particular bullet in the name of compliance. With regard to my other questions, it appears to me that there is a slight disconnect in the mapping between Atom and hAtom, i.e. 1. Atom's atomEntry has atomSource, but hAtom's hentry doesn't appear to have a corresponding 'entry-source' or equivalent. I think you're presenting the first use case for this in hAtom. 2. The schema description at http://microformats.org/wiki/hatom#Entry_Content states that 'entry-content' is 'required', but a little later on it merely says that "an Entry SHOULD have Entry Content". The Atom spec itself seems to be silent on whether 'atomContent' is required or desirable. For Atom, "content" is intended to be used for full content (the entire article, blog post, whatever) while "summary" is intended to be used for "a short summary, abstract, or excerpt of an entry". The idea being that feed providers can be very explicit about what they're providing, and feed consumers can know what kind of thing they're dealing with. It's quite reasonable to have a feed of just summaries if that's what you want to publish (IMHO). -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
Couple of minor notes below... David Janes -- BlogMatrix wrote: Angus McIntyre wrote: These lists of articles - which are essentially 'feeds' - seem like an obvious match for hAtom, so I've tried to make the library produce hAtom. However, there are some problems. First, hAtom demands an author - either at the entry level, or at the feed level - and in these two use cases, there's no obvious author. In the case of the Inca Trail collection, the articles linked to sometimes have authors and sometimes don't. I could put myself as the 'author' of the collection as a whole, but I'm not sure that makes strict sense. I would suggest going with your latter option, even though it's a little ugly. At that point, we're really constrained by the Atom spec and in some technical sense you (or some contact at your organization) is the author of the feed even though you're not the person creating the content of the individual entries. Note: The Atom spec provides the atom:source element to handle this. If an extension to hAtom is needed, that's probably the place to look. Second, hAtom demands 'entry-content' and makes 'entry-summary' optional. In the first example, there's neither content nor summary (because that's how the client wants it). In the second, the text is really more in the nature of a summary than content, but content is the required item. Atom demands entry:content, hAtom assumes it's the empty string [1] if you don't add it. Actually, Atom doesn't require entry content, just advises that one of summary or content should be present: Experience teaches that feeds that contain textual content are in general more useful than those that do not. Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. Feed producers should be aware of these issues. It is advisable that each atom:entry http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.entry element contain a non-empty atom:title http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.title element, a non-empty atom:content http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.content element when that element is present, and a non-empty atom:summary http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.summary element when the entry contains no atom:content http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.content element. However, the absence of atom:summary http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.summary is not an error, and Atom Processors MUST NOT fail to function correctly as a consequence of such an absence. -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview 0.3 drafted
Tantek elik wrote: Greetings, I've taken the changes proposed and accepted for hReview 0.3 from the review-brainstorming page and incorporated them into hReview: http://microformats.org/wiki/hreview Question: If reviewer is absent from the hReview, then look outside the hReview, in the context of the page, for the reviewer. If there is no "reviewer" outside either, then use the address for the page as the reviewer. What if the review is embedded in something other than a web page, say a feed? (Or an email, but I think a feed falls in the 80% case.) A reasonable thing to do would be to use the authorship rules for the Atom or RSS feed, looking up the XML tree. -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview implementation feedback sought
No, but please jump in: http://www.microformats.org/wiki/aggregate-review-examples Paul Bryson wrote on 2/6/2006, 12:16 PM: Has the hReview format been updated to work with aggregates yet? Atamido Ben Griffiths [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Greeting microformateers, We've just put live an early cut of http://www.reevoo.com - a uk- based review aggregator for reviews of electrical products. We're using hReview as an aggregation format and we'd appreciate any feedback from the mavens of that microformat that frequent this list . We're especially keen to get feedback on whether our review creator creates hReview mark-up that's interoperable with other people doing the same thing in this space. We're hoping for a big public launch in a few weeks time - after we've fixed the inevitable internet explorer glitches and done some more design work - so don't be too harsh on us yet! Thanks to everyone who's worked on the hReview format - we'd love to see it go from strength to strength. Yours, Ben Griffiths CTO, Revieworld Ltd ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- John Panzer Sr. Technical Manager http://journals.aol.com/panzerjohn/abstractioneer ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview for Stocks
Paul Bryson wrote: John Panzer wrote... Yep, in the usages I've seen, people tend to use either the name or the individual ticker symbol interchangeably in text. That is, the difference between Buy Time Warner now! and Buy TWX now! seems to be mostly a matter of style; Microformats in spam? Wow, that is some serious market penetration. Real world spam example duly added to http://microformats.org/wiki/stock-symbol-examples. :) -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview for Stocks
Tantek Çelik wrote: I could however see using abbr to remove the name of the market/trading-floor, since common stock discussions usually omit that (since it is often implied by the ticker), and only provide the ticker symbol: e.g. abbr title=NasdaqNM:MSFTMSFT/abbr Yep, in the usages I've seen, people tend to use either the name or the individual ticker symbol interchangeably in text. That is, the difference between Buy Time Warner now! and Buy TWX now! seems to be mostly a matter of style; human readers figure out from context what's being said. In either case they're using an abbreviation. I also see usages similar to the ones below when the ticker symbol is actually mentioned along with the company name. These usages would let us just mark up the human readable content: Buy Time Warner (NYSE:TWX) now! Shares of Tractor Supply (TSCO:Nasdaq - commentary - research - Cramer's Take) I made my top pick Quality Systems (Nasdaq: QSII) The last two are copied and pasted from Yahoo! and Fool.com, respectively. Note the amusing lack of consistency in the ordering of exchange and ticker symbol in the last two. If we actually want to be able to simply mark these up semantically, without imposing changes on the human readable text, I think we need two elements. For example, class=exchange and class=ticker. And that's the right way to do it. But in the Buy TWX now! case we still need abbr. All of this seems to indicate that we do need a stock symbol microformat in order to be able to (a) mark all of this up properly while (b) embedding it as a reviewable thing inside hReview or as additional data inside an hCard representing a business. We've been trying hard not to invent new microformats but it sure looks like it's time to go to the Wiki page. Here's the logical structure I think is needed: ticker symbol (required) exchange (required) (possibly) country (definitely not required) All of which can be marked up using abbr if necessary. OK, off to http://microformats.org/wiki/stock-symbol-examples. -- John Panzer Sr Technical Manager, AOL http://journals.aol.com/panzerjohn/abstractioneer ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview for Stocks
Ryan King wrote on 2/1/2006, 3:49 PM: On Feb 1, 2006, at 2:27 PM, John Panzer wrote: ... One goal is to ensure that the human readable content is able to remain the same as today. I'm not sure what the significance of this statement is. In order to evangelize microformats, it's very useful to be able to tell people that they won't have to change their carefully-chosen human-readable writing style. Obviously if someone is following an unwise writing style, they may not be able to take advantage of all of the benefits of microformats, but I don't think we should dictate to them that they have to do things a certain way. Persuade, yes. ... IMHO, given the difficulty in seperating the two (company and stock), I doubt we'll ever be able to create One True Way to Review Stocks. People confound stocks and companies, though they are not precisely the same thing. We may just have to live with that. Yep, I think this is a question which really doesn't need to be answered for many (most) purposes, actually. Whatever they're talking about, it has a name, some kind of URL, and an associated stock ticker symbol that is a non-URL unique identifier. If this were a VC blog it might suggest the former. In either case, though, we'd like to be able to mark up the ticker symbol in some semantic way, and that's the primary goal of this query. Definitely an open question. I think it requires research. How do people currently refer to ticker symbols, stocks and companies on the web? Benjamin Carlyle did some research on the mailing list this month, but there didn't really seem to be a lot of useful formal prior art. Apparently in most cases people use the ticker symbol string and exchange identifier (or country -- apparently exchanges within a country guarantee uniqueness of symbols). For example, NYSE:TWX, or USA:TWX. For more general company information hCard would seem to work just fine. Note that we're not trying to fully describe a tradable commodity with all of its attributes (that would be a whole other thing); rather, we're just trying to uniquely identify such a thing using the ways that humans typically do that. ... 2. Use XHTML 1.0 following Appendix C - Compatibility. Empty span/ elements are not compatible XHTML 1.0. I'm a little confused; it certainly seems to be valid XHTML 1.0 Strict according to http://validator.w3.org/check. Do you mean that it may cause problems when served as text/html to some browsers? If by some browsers you mean WinIE, then yes. Remember, WinIE doesn't grok xml at all and does everything in html mode. Sure, but when just discussing a microformat I don't think that's relevant, is it? Yes, it is. Microformats must be renderable in existing browsers. Sorry, I wasn't clear. Sujata was just giving a non-normative example of how this might work for human discussion purposes, using an abbreviated syntax that is awfully convenient when dealing with XML. It's definitely not intended to be something to be consumed by any browser. ...how to extend hCard to handle additional types of item annotations isn't clear from the spec or FAQ. The general answer is that you can always use additional semantic (or not so semantic) classnames. I should have said hReview above. The specific question that came up was where exactly those classnames need to be added in order to follow the hReview rules. ... ...in which case, perhaps what we really need is a new nanoformat: a class=item fn href=...abbr class=ticker title=NYSE:TWXTime Warner, Inc./abbr/a ...though semantically I think this is a bit dubious. Also, it doesn't extend very well to additional values/attributes. Thoughts? As I mentioned above– unless I missed it, there doesn't appear to be any research on how people refer to stocks online. See Benjamin Carlyle's message per above. I haven't been able to find much myself. Mostly people appear to use the ticker symbol (alone, no I18N there) and perhaps hyperlink to their stock-quote-provider-of-choice. Unless we have significant research which demonstrates a specific behavior here, I would not be inclined to do anything special for stocks (beyond a normal product/business review). I think there are really two questions here: (1) What's the right way for us to review a stock, and (given that we have a requirement to identify the ticker symbol) the right way to let us add those semantic classnames without breaking the microformat? (2) Is there any interest in standardizing on the classname(s) used in #1 so the result would be useful to other people? I can easily see us getting an consensus on #1 and a No to #2, which would be fine. I think Sujata needs to do more research on the expiration business. It's not at all clear to me if this is something of general use or something specific to this one application
Re: [uf-discuss] hReview for Stocks
Tantek Çelik wrote: On 2/1/06 2:27 PM, John Panzer [EMAIL PROTECTED] wrote: Would this be acceptable as a structured fn? a class=item fn href=...abbr title=NYSE:TWXTime Warner, Inc./abbr/a Well, you could use that markup, but there are several questionable things going on here. ... 2. Both NYSE and TWX are abbreviations and thus proper use of abbr requires that they be *inside* the abbr rather than an attribute. e.g. abbr title=New York Stock Exchange, Time Warner Inc. common stockNYSE:TWX/abbr Hm. I disagree with this, or at least I need a clarification. I don't see a fundamental difference between using abbr title=NYSE:TWXTime Warner/abbr and using abbr title=20050125January 25th/abbr? [1] Specificially, in this particular context, Time Warner is the simple, human readable, friendly, but possibly ambiguous abbreviation of the stock ticker symbol NYSE:TWX. Just as January 25th is the simple, human readable, but ambiguous abbreviation of 20050125. The key distinction here is that I'm not using NYSE or TWX as abbreviations for anything in this particular context; together they're forming a unique identifier whose constituents happen to map pretty well to certain English words. But they don't always; there was a time period when AOL was the NYSE ticker symbol for the company officially named Time Warner. From http://microformats.org/wiki/cite for example: Finally, if the format of the data according to the original schema is too long and/or not human-friendly, use abbr instead of a generic structural element, and place the literal data into the 'title' attribute (where abbr expansions go), and the more brief and human readable equivalent into the element itself. [1] http://tantek.com/log/2005/01.html#d26t0100 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] CSS Skin Manifest Microformat?
All, I'm currently working on ways to 'skin' content-based web pages using open, standards based techniques. My goals are to come up with a way to style things like blog pages, wikis, and modules within these types of pages, in a way that is safe, is totally content-agnostic, and can be tweaked by non-programmers. The obvious answer here is "use CSS style sheets" and that's of course exactly what we're doing. As we all know, though, CSS doesn't cover all the things that it really should, and we're also interested in being able to provide enough metadata to describe things like skin themes, or "a theme with five color variations, pick one variation at a time" in one package, provide thumbnail previews, have related skins for related pages (like the front page of a blog vs. an individual entry page, which might get slightly different yet consistent styling) .We're also interested in a packaging system to let people grab, tweak, and mash up skins as much as possible. Prior art includes: o MSN Spaces themes (categories like Animals, Music, Occasions, Simple themes, Art, Nature...) and thumbnail previews of themes like "Green Flowers", "Blue Flowers", "City Skyline", etc.) Mostly sets background images and colors. Not a lot of customization possible. Doesn't affect custom content added to page. o LiveJournal Layout/themes (names like 3 column, A Novel Conundrum, Classic, Variable Flow...) and variation themes within each layout (Blue/Black/Red). Layouts include layout and display decisions, and variation themes just tweak colors for the most part. o Blogger templates -- control all content, including CSS styles and an HTML content skeleton. Names like "Dots", "Dots Dark", "Harbor". Changing a template deletes all customizations or content other than the basic blog entries for each blog. o All the various custom CSS styles/color theme pickers that appear on web sites to dynamically update the colors/themes/etc. Extreme example is of course CSSZenGarden, but that CSS is very content-specific (and we're looking for content-agnostic styles). Naturally, we have a microformat proposal draft already in progress as well as some prototype implementations but I'd really like to throw this out first to see what kind of interest there is in this problem space. One other requirement I'd thought of is that there might be a good reason to use "microskins" corresponding to particular microformats, providing default looks for things like hCard, hCalendar, etc. Perhaps the ability to compose skins would be useful. One of the things we're running across that CSS doesn't handle is the need to utilize _javascript_ to get a reasonable approximation of rich web page designs. It's possible to do things in a cross-browser, standards compliant, content-agnostic, semantic-markup, non-scripted way; pick any four out of five. On the other hand, _javascript_ might not be acceptable in some cases; it's useful to have a way to declare up front what the requirements are. Having a way to say "this site is compatible with hSkin 1.1 (_javascript_ OK)" in a machine readable way might be useful. As an aside, of course we're working have this operate smoothly with Kevin Lawver's modules. They're nicely complementary. -- John Panzer Sr. Technical Manager http://journals.aol.com/panzerjohn/abstractioneer ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: how to do aggregate reviews - Re: [uf-discuss] hReview feedback
As Tantek suggsted, I started a page documenting some of the potential examples for aggregate reviews here: http://microformats.org/wiki/aggregate-review-examples Please add additional examples if you have any -- I'll look for some more but have negative spare time right now. -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hReview on stocks
Is there a recommended way to use hReview to rate stocks? I think everything maps very well except that the target of this particular review is neither a person nor a web resource, but a stock ticker symbol. (Note that ticker symbols aren't tied 1:1 to organizations, so using hCard doesn't seem appropriate.) Of course I can simply make up a unique URL per ticker symbol easily enough, but that seems hacky. Any thoughts? -- John Panzer Sr Technical Manager, AOL http://journals.aol.com/panzerjohn/abstractioneer ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Interest in stock ticker microformat?
I have a use case[1] for embedding ticker symbol metadata into blog posts -- with fields like company name, symbol, exchange, country, etc. There's an existing if proprietary XML format for this data which lends itself to a very simple structured-blogging-style embedding via script tags or (ugh) HTML comments. We're likely to use that for a short term solution. I'd like to propose an alternative or at least accompanying microformat as well -- has anyone done any work on this? I'll throw something up on the wiki when I have some time, but I'm lazy and would love to adopt or adapt someone else's work. -- John Panzer Sr. Technical Manager http://journals.aol.com/panzerjohn/abstractioneer [1] http://journals.aol.com/hilaryonstocks/hilaryonstocks ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
