[uf-discuss] hReview for Stocks

Wed Feb 1 18:02:01 PST 2006

On 2/1/06 2:27 PM, "John Panzer" <jpanzer at aol.net> wrote:

> Tantek Çelik wrote on 2/1/2006, 12:25 PM:
> 
>> On 2/1/06 12:04 PM, "Sujata Ramchandran" <sramchandran at aol.com> wrote:
> ...
>>> I have been asked
>>> to provide some additional fields within hReview
>> 
>> Who has asked you for this?  That might help understand what the
>> problem is that you are solving.
> 
> I should note that Sujata and I work together at AOL,

Ah ok.  I can never tell if an aol.com is someone who works at AOL or
someone who simply uses an AOL account for their email. ;)

> and this is an 
> outgrowth of the query I sent on 1/18 entitled "hReview on stocks" which
> motivated the addition to the hReview FAQ regarding stocks and companies.

Makes sense.

> The motivating example is:
> http://journals.aol.com/hilaryonstocks/hilaryonstocks
> 
> For example:
> 
>  Exxon Mobil (NYSE: XOM): In This Case, Bigger Really Is Better
> 
>  When talking about big companies, they don¹t get much bigger than
>  Exxon Mobil. This company is a monster, in terms of revenues, earnings
>  and market cap blah blah blah...

It's definitely good to start with an example.

Are there others besides just this one?

> Note that the first line is a title which at least currently doesn't
> allow markup,

Huh?  Viewing source...

<div class="entry_title">Exxon Mobil (NYSE: XOM): In This Case, Bigger
Really Is Better</div>

You (the hosting platform, the template author, etc.) can put plenty of
markup inside there.

> and the stock ticker symbol is actually nowhere mentioned
> in the body which does allow markup.  So there's a dissonance here
> between what the writer wants to display and what we want to be able to
> automatically extract.

>From the user's point of view how are you distinguishing that this is a
review at all, rather than just a blog post?

At the point where you decide to allow custom input fields (perhaps rating
etc.) to provide a review UI, if you're looking to get reviews of stocks in
particular, it makes the same sense to have custom fields for information
about the stock itself.

> One goal is to ensure that the human readable
> content is able to remain the same as today.

That seems easily achievable, using <span> for example.

> I think everyone agrees this is a review (right?), but there's a
> question about what's being reviewed (the company or its stock); of
> course this is a blog about stock picks which suggests the latter.

Right.  From the context it is clear the author is reviewing the stocks.

> 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.

As suggested in the FAQ, if that is the goal, then the *stock* should be the
item, which is closest to a *product* for purchase, and you might as well
use the common naming convention for stocks, e.g. "NYSE: XOM" in the above
example for the "fn" of the item.

In addition, I also realized that the same answer to "What do I do about
reviews for movies in particular?" also applies to stocks, and any other
kind of product.  Tag it!  I've added to the FAQ entry accordingly.

>>> Here's what I am suggesting based on the parameters that I have been
>>> given.
>> 
>> Could you provide the parameters that you have been given?
> 
> One issue we're grappling with is that it's difficult for us to get a
> concrete set of requirements which don't amount to 'provide exactly what
> our undocumented proprietary API needs'.

Ugh, yeah, that's certainly no fun.

> So please bear with us as we try to evangelize microformats.

We're with you!

>>> <div class="hreview">
>>> <span class="item ticker" title="TWX"/>
>>> <span class="item exchange" title="NYSE"/>
>>> <span class="item country" title="USA"/>
>>> <span class="item expiration" title="20050518T2300-0700"/>
>> 
>> 
>> There are a few microformat and hReview fundamentals being violated here.
>> 
>> 1. Visible data.  The ticker symbol, exchange, country should be
>> visible in
>> the text as the reviwer would write them.
> 
> We're not happy about this either.  We may not have a choice to start with.

If it's not visible, it doesn't belong in the microformat.

>> 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?  Sure, but
> when just discussing a microformat I don't think that's relevant, is it?

It is.

For all intents and purposes, you should always assume that Appendix C
matters when using/publishing XHTML.

I strongly recommend you read it thoroughly:

http://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines

>> 3. There may only be one "item" per "hreview".  I thought this would be
>> obvious from the spec, but it apparently isn't, and it should be made
>> explicit.  I have added this as an issue to hreview-issues:
>> 
>> http://microformats.org/wiki/hreview-issues
> 
> That's a really good point.  There's only one logical item of course,
> but how to extend hCard to handle additional types of item annotations
> isn't clear from the spec or FAQ.  Something to add?

Actually, it's not clear we want to extend hCard, and that any effort to do
so should definitely be done with *quite* a bit of research.  The closest
candidate for this is all the discussion of having a "profile" microformat.

First, if this is a review of a stock, then it shouldn't be an hCard, since
a stock is more like a product than a business.

Second, hCard does have tags (see "category" in the hCard properties), thus
you can tag hCards with any number of tags.

> So this is presumably acceptable:
> 
> <a class="item fn" href="...">Time Warner, Inc.</a>

Only sort of.  If you are reviewing the company, Time Warner, Inc. (because
there could be numerous different securities besides just Time Warner common
stock), then yes, but in that case, since you are reviewing a
business/organization, you SHOULD use a complete hCard per hReview 0.2, and
in hReview 0.3 this requirement changes to a MUST.

> But doesn't lend itself to automatic parsing of the stock symbol, which
> is a primary goal.

Then the stock symbol itself should be used as the name.

> Would this be acceptable as a structured "fn"?
> 
> <a class="item fn" href="..."><abbr title="NYSE:TWX">Time Warner,
> Inc.</abbr></a>

Well, you could use that markup, but there are several questionable things
going on here.

1. It conflates a ticker symbol for a specific security and a company name
(as noted, companies can have many different kinds of securities, stocks,
bonds, etc.).

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.

3. From an hReview perspective, the "fn" is on the <a>, and thus the text
node content of the <a> is what would be the value of the fn, in this case
"Time Warner, Inc."

> ...in which case, perhaps what we really need is a new nanoformat:

Whether it is one class/rel value or a few, it's still a microformat ;)

> <a class="item fn" href="..."><abbr class="ticker" title="NYSE:TWX">Time
> 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?

This is why I pointed out that is exactly what it sounds like you are trying
to do in my previous email on this subject, that is, introduce a new
microformat to talk about a stock symbol in particular, and that requires
research independent of hReview.  If you want to pursue this, I'd suggest
starting with an examples page that documents how people mention stocks on
web pages today:

 http://microformats.org/wiki/stock-symbol-examples

> 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.  (E.g., one could imagine an
> hReview extension saying that a review should only be considered valid
> for a month, and treated as historical data thereafter.  Not sure how
> widely applicable this is, nor whether this is really the semantics that
> are desired by our customers.)

I don't think I've seen it in *any* real world review examples.

 http://microformats.org/wiki/review-examples

If you have examples of the web of people publishing review expiration
dates, please add them to the wiki page so we can analyze them.  However,
given that the extensive research so far has yet to find any, I'm not sure
it makes sense give the 80/20 principle.

I hope this helps clarify some points and provide options (so to speak) for
moving forward.

Thanks,

Tantek