Areas of interest
ja...@scrugy.com
relates to this project.
Here are some of my thoughts:
- I think there is a lot of value in illustrating in very simple terms
how existing microformats can be used in the wine industry and what the
potential is. Given that there will be a varying degree of technical
experience for the people that will be involved, we can't make
assumptions about what people know and don't know when it comes to
applying these concepts.
- There is some work to be done to be able to standardize how we
identify a wine. UPCs cannot be counted on. The wine name can vary from
site to site. Is the concept of a released wine separate from a
specific bottle of wine. I remember seeing a site that was trying to
formulate a universal code for wines (like a UPC) but can't find it
now.
- Any interest in a universal wine directory or network for wines,
producers, regions? In order for us to be able to uniquely identify
wines. I think there was some discussion about this on the REthink blog
a while ago. Does this apply?
- I'd like to explore how wines, tasting notes, wineries, varietals,
vineyards, and regions can be expressed in microformats. For wines,
they should be represented as items as well as listed for sale.
What am I missing? Thoughts?
James
Sagi
I definitely think there is value in adopting microformats for wine. I
am of the opinion that the project should start with standardizing the
wines themselves. Without a way to standardize the wine that the
reviews relate to, I don't know how much value we can draw from a
review microformat. We need to make sure that all the reviews are
pointing to the correct wine.
Thanks for starting this discussion. I think there is a lot that we
can do here.
Sagi
James Jory
> Without a way to standardize the wine that the
> reviews relate to, I don't know how much value we can draw from a
> review microformat. We need to make sure that all the reviews are
> pointing to the correct wine.
>
class for the "item") and derive some information but it's error prone
and difficult to fully parse. This is essentially what the Scrugy parser
is doing now. It makes multiple parsing passes over the wine name
attempting to match combinations of elements of the name against
well-known patterns, abbreviations, varietals, appellations, producers,
and label designations. Often every element of the name can be matched
against an existing wine but you still have to make an assumption on the
match.
As an aside, would there be any interest if I exposed the wine name
parser as a web-service? You'd pass in a wine name and the web service
would return the fully-qualified elements with meta information about
each element. For example, tasting notes for the wine, aggregated
community score, producer contact & GPS information, region of origin
information, and so on.
-James
El Jefe
component: the "what's the value for me?" Winery people will be cool to
make the effort to use microformats unless there is a clear advantage
to doing so. And even then it had better be damned easy to do! Think:
fill out a form, cut, paste. Or something very similar. It would need
to be as easy as, say, google analytics to add to a web page.
I agree with Sagi about standardizing the wines and having the reviews
point at the correct wine. I am less concerned with review keywords - I
think by their very nature they are imprecise. If a consumer is
searching for reviews on my Verdelho, but if Verdelho is misspelled on
half of the review sites out there they aren't going to find them.
I also agree that UPC is no good, because the UPCs get reused (we reuse
the same UPC for subsequent vintages, it's what the stores want,
apparently.)
I just joined your group and plan to be the skeptical curmudgeon winery
guy with a programming background trying to keep you honest...:)
cheers! - j
ja...@scrugy.com
> hi James - whatever you do there has to be a significant marketing
> component: the "what's the value for me?"
I agree. A clear value proposition will be critical. However, before we
can market the concept we need to figure out how wine and the semantic
web fit together. In other parts of the web there are some good
examples of what can be gained by incorporating microformats into site
content. Look at what Technorati (http://technorati.com) is doing in
the blogging world with tags and links. Flickr is using tags and
metadata in photos to reinvent how photographs are organized. And
Eventful (http://eventful.com) and Upcoming.org (http://upcoming.org)
are leveraging well-known event meta formats including the hCalendar
microformat.
> And even then it had better be damned easy to do! Think:
> fill out a form, cut, paste. Or something very similar. It would need
> to be as easy as, say, google analytics to add to a web page.
Absolutely. This is where the technical folks in the wine community
need to step up and create tools and services to make taking this step
easy and painless.
> I agree with Sagi about standardizing the wines and having the reviews
> point at the correct wine.
This is certainly one of the biggest challenges. Once this issue is
solved, I think everything else will fall into place. However, I also
think that this will only work if an open standard is defined that is
easy to understand and adopt.
> I am less concerned with review keywords - I
> think by their very nature they are imprecise.
When done right, I think review keywords can be an incredibly powerful
tool that can help consumers to not only build a wine vocabulary but
also help them recognize what they really like and dislike in wines.
> If a consumer is
> searching for reviews on my Verdelho, but if Verdelho is misspelled on
> half of the review sites out there they aren't going to find them.
Misspellings and abbreviations can be the cause of mismatched data but
I think technology can help out here by making sure that wines are
identified properly (the "garbage in" side) and applying techniques
like phonetics on the backend to fix-up any errors that make it in.
> I just joined your group and plan to be the skeptical curmudgeon winery
> guy with a programming background trying to keep you honest...:)
Welcome! Thanks for getting involved. Your perspective as a winery guy
with a technical background will be very valuable.
juice...@gmail.com
>> As an aside, would there be any interest if I exposed the wine name
> parser as a web-service? You'd pass in a wine name and the web service
> would return the fully-qualified elements with meta information about
> each element. For example, tasting notes for the wine, aggregated
> community score, producer contact & GPS information, region of origin
James, this would be very interesting.
Thanks for starting this. I'm not going to proclaim to be a
microformat expert but I'll help out where I can. Microformats for
wine reviews is a great idea and really the semantic web would help the
wine world tremendously...if it were adopted widely.
I guess thats the key - adoption. El Jefe is totally right - the value
has to be clear and the ease of use has to be there. I think I may be
able to help out there a bit. But, if you build it, will they come?
Who are the targets (to use wine microformats):
* Wineries
* Bloggers
* Wine Retailers?
who else?
Then its an excercise of demostrating the value to these users (maybe
this should be a different thread)
ja...@scrugy.com
> On Nov 17, 3:47 pm, James Jory <j...@scrugy.com> wrote:
> > As an aside, would there be any interest if I exposed the wine name
> > parser as a web-service? You'd pass in a wine name and the web service
> > would return the fully-qualified elements with meta information about
> > each element. For example, tasting notes for the wine, aggregated
> > community score, producer contact & GPS information, region of origin
>
> James, this would be very interesting.
Yeah, I think it would be interesting to see what kind of apps or
widgets people could build off such an API. For example, say a blogger
references a wine in a post and hyperlinks the wine name to execute
some JavaScript when a reader hovers over the link. The hover handler
would make the API call and display a popup DIV with detailed bits
about the wine from the response. The reader could then click on links
in the DIV to learn more about the winery or region where the wine came
from or visit a map page showing where the winery is located (assuming
geo data was available). Just a few thoughts off the top of my head.
> I guess thats the key - adoption. El Jefe is totally right - the value
> has to be clear and the ease of use has to be there. I think I may be
> able to help out there a bit. But, if you build it, will they come?
Won't know until we give it a shot. This is an initiative that we all
can benefit from if done right.
> Who are the targets (to use wine microformats):
> * Wineries
> * Bloggers
> * Wine Retailers?
>
> who else?
All of the above. Some others to consider include wine communities
(forums and custom-built sites), restaurants & wine bars (wine lists),
cellar management sites, wine event sites, wine region association
sites, and wine critics.
> Then its an excercise of demostrating the value to these users (maybe
> this should be a different thread)
Since there seems to be several different types of users of
microformats and several microformats that can be employed, perhaps we
should pick a specific application of microformats and start there.
I've already done some work with wine reviews and hReview. I'm also
interested in how wineries can use microformats on their sites.
One issue that seems to always come up quickly when you start thinking
about this stuff is how to accurately represent a wine. There is some
progress being made within the microformat community for defining an
"item" or "thing" microformat that we could then use to represent a
wine but these efforts are meeting resistance.
So what would a wine look like if it were formatted using the "item"
class? Perhaps there would be "wine" class that would further define
that the item being defined is indeed a wine (important in cases where
other non-wine items were present on the same page).
Here's an example from a tasting note from my personal blog.
<h2 class=”item wine“>
<span class=”fn“>
<span class=”vintage“>2003</span>
<span class=”producer“>Scott Harvey</span>
<span class=”designation“>Mountain Selection</span>
<span class=”varietal“>Zinfandel</span>
<span class=”region“>Amador County</span>
</span>
<span class=”country“>USA</span>
<abbr class=”alcohol” title=”14.5″>14.5%</abbr>
</h2>
Obviously there is much more that can be specified for a wine but these
are the biggies. Also, all of these fields wouldn't be required. And
keep in mind that this content can stylized with CSS and moved around
as desired (i.e. they don't have to be within an <h2>).
Thoughts?
juice...@gmail.com
I know everyone hates WS, but lets face it, they're 80% of what people
read and expect. As a starting point - say "Wineformat v1.0" - we
translate WS ratings into a microformat.
Keeping it simple and in a form that everyone knows. Otherwise the
scope is nearly infinite.
WS uses:
Winery
Wine
Score
Notes
Price (in USD)
Country
Region
We should add:
vintage
designation
Question about "varietal" - what about Old World and Meritage? Do we
orient this towards New World (ie by varietal) or Old World (ie by
region, designation, vintage)?
Tim Elliott
Question about "varietal" - what about Old World and Meritage? Do we
orient this towards New World (ie by varietal) or Old World (ie by
region, designation, vintage)?
Thanks,
--
Tim Elliott
Winecast
ja...@scrugy.com
> Here's a thought -
>
> I know everyone hates WS, but lets face it, they're 80% of what people
> read and expect. As a starting point - say "Wineformat v1.0" - we
> translate WS ratings into a microformat.
I really like the idea of taking something that is familiar to most
people (WS rating) and showing how it can be expressed with a
microformat. In fact, many publications and sites follow this same
approach so it's practically universally applicable.
> Keeping it simple and in a form that everyone knows. Otherwise the
> scope is nearly infinite.
>
> WS uses:
>
> Winery
> Wine
> Score
> Notes
> Price (in USD)
> Country
> Region
>
> We should add:
> vintage
> designation
I would add the wine type to this list too (red, white, rose, sparkling
white, sparkling red, port, and so on).
Also, I think winery/producer, vintage, designation, and region are
often fully defined or implied in the wine name. Of course not all of
these elements are required and you can derive missing values in many
cases. For example, from the wine name "2001 Pio Cesare Barolo Ornato"
you can derive that the varietal is Nebbiolo, the wine type as red, the
country is Italy, and the region is Piedmont even though none of these
values are declared in the name. Of course this linkage is only
possible by having system knowledge that Barolo comes from the Piedmont
region in Italy and is made from Nebbiolo.
> Question about "varietal" - what about Old World and Meritage? Do we
> orient this towards New World (ie by varietal) or Old World (ie by
> region, designation, vintage)?
I think that in order to be successful, all known elements of a wine
name must be able to be represented. As you pointed out, there is no
universal wine name standard. New World v. Old World are the two
broadest categories of wine name formats/styles but even within
countries there are naming differences that fall along appellation
lines. France's AOC regulations for wine naming and labels can vary
significantly from appellation to appellation.
Within Scrugy I have established the following general rules when it
comes to the elements of a wine name:
Vintage (optional): Interpreted as non-vintage when missing.
Producer/winery name (required): Can take the form of the winery's full
name or what I call the short name (e.g. short name for "Miner Family
Vineyards" is "Miner").
Varietal (optional*): Chardonnay, Merlot, Pinot Noir, and so on. More
of a new world naming element but starting to become more common in old
world regions.
Region/appellation (optional*): Napa Valley, Burgundy, Chianti, and so
on.
Designation (optional*): represents the label designation (e.g.
"Oracle" for Miner's red blend). Unofficial but accepted "styles" such
as White Zin and Meritage can fall in here too.
Vineyard (optional): represents a vineyard designation such as "Garys'
Vineyard" or "Ornato" from the Barolo example above)
* = at least one of these 3 elements is required
Thoughts? Are there holes in this approach? Any interest in factoring
this out as a meta rule of some sort to serve as a guideline for a wine
review microformat?
werner
Jason Coleman (winelog.net) just pointed your group out to me. My name
is Werner Bruhin, I am the author a cellar book software
(www.thewinecellarbook.com) and one of the co-authors of vinoXML
(www.vinoxml.org).
Looking at MicroFormats, especially hReview I am not sure if this would
be that great for wine. While one can probably use it I think it would
still need a sophisticated parser to read it and store it in ones own
database schema, as it leaves a lot of thing "open" (kind of like we
did in vinoXML with the "tastingExtendedDetail" - it is way to open and
just about unusable).
I would hope that the schema (vinoXML) we put together might be useful
to you all. When we started this we wanted to create a mechanisme to
exchange information on wine between programs (could originate from a
web site, cellar book or whatever) and make it easier for each
developer to parse the information (i.e. no more guessing if the wine
name is after the label "wine name:", "Weinname", "Designation de vin"
etc).
The format is standardized using a W3C schema and we standardise some
codes (i.e. country code is ISO3, some other things are defined in
enumerations within the schema), but we did not think that much more
was possible, at least initially.
Currently there are two cellar book programs out supporting the
standard and while an import is not 100% it is still faster then
manually keying everything in.
There have been a few posts to the forum on vinoxml showing interest
and we are open to change/enhance the schema over time.
James the universal code for wines site is probably ISWN
(http://www.iswn.org/iswn_org/iswn_info/index.cfm).
You might also want to look at:
http://www.warpa.com/warpa_com/index.cfm
http://www.woochi.com/
The things I have on my TODO list is to work on version 1.1 of the
schema, which should include a better "tastingExtendedDetail"
complexType element in the schema and I would also like to look at how
we could support ISWN standard codes. I'll allow myself to post here
when we start the discussion on 1.1 on vinoXML and maybe some of you
might want to join in.
Best regards
Werner
ja...@scrugy.com
> Hi Everyone,
>
> Jason Coleman (winelog.net) just pointed your group out to me. My name
> is Werner Bruhin, I am the author a cellar book software
> (www.thewinecellarbook.com) and one of the co-authors of vinoXML
> (www.vinoxml.org).
Thanks for joining the discussion, Werner. Your experience and
perspective are valuable.
> Looking at MicroFormats, especially hReview I am not sure if this would
> be that great for wine. While one can probably use it I think it would
> still need a sophisticated parser to read it and store it in ones own
> database schema, as it leaves a lot of thing "open" (kind of like we
> did in vinoXML with the "tastingExtendedDetail" - it is way to open and
> just about unusable).
I'm sorry but I think you're misunderstanding the purpose of
microformats. Microformats are not data interchange specifications.
They are simply a way to embed semantics in HTML. Please checkout
http://microformats.org for details.
Also, within the context of what we're trying to do here and what I
believe is the purpose of vinoXML, I do not think this is a wineformats
vs. vinoXML issue. They are trying to solve different problems and for
different users. Microformats are for humans first, machines second.
XML (and vinoXML) are for machines first, humans second. Should a
blogger who simply wants to write up a tasting note with meaningful
semantics be required to understand the vinoXML schema? Do they have to
write their tasting note twice (once in HTML and once in vinoXML)? Now
if we're talking about two wine-related applications/services that want
to exchange wine data, I think vinoXML is a great match.
Regarding parsing microformats, this is not sophisticated at all.
Microformats build upon the most widely used markup spec in use today
(HTML) and there are parsers available in several programming
languages. In addition, microformat-aware email programs and browser
plugins are starting to emerge that will allow end-users to use the
information embedded in web pages and RSS feeds in meaningful ways.
> I would hope that the schema (vinoXML) we put together might be useful
> to you all. When we started this we wanted to create a mechanisme to
> exchange information on wine between programs (could originate from a
> web site, cellar book or whatever) and make it easier for each
> developer to parse the information (i.e. no more guessing if the wine
> name is after the label "wine name:", "Weinname", "Designation de vin"
> etc).
I think vinoXML will be useful to those of us who are developing
software for the wine industry but I think wineformats are more useful
to publishers of wine content (bloggers, winery site developers, wine
event publishers, wine communities, and so on).
I was not familiar with vinoXML before your post and I have only spent
a few minutes on vinoxml.org but it's clear that the contributors have
spent a lot of time defining the schema. I think there is potential for
each group to learn from each other and work together.
> James the universal code for wines site is probably ISWN
> (http://www.iswn.org/iswn_org/iswn_info/index.cfm).
Yep, that's the one. Thanks.
> The things I have on my TODO list is to work on version 1.1 of the
> schema, which should include a better "tastingExtendedDetail"
> complexType element in the schema and I would also like to look at how
> we could support ISWN standard codes. I'll allow myself to post here
> when we start the discussion on 1.1 on vinoXML and maybe some of you
> might want to join in.
Sounds great. I'm interested.
Regards,
James
werner
If ever I come across a bit harsh, please just write it off to me being
Swiss German.
Anything I say is just my opinion, which can relatively easily be
changed if one pushes some arguments down my throat :-)
ja...@scrugy.com wrote:
> I'm sorry but I think you're misunderstanding the purpose of
> microformats. Microformats are not data interchange specifications.
> They are simply a way to embed semantics in HTML. Please checkout
> http://microformats.org for details.
>
I did not see how one defines what is valid and what is not type of
stuff. But I will have another look at it.
> Also, within the context of what we're trying to do here and what I
> believe is the purpose of vinoXML, I do not think this is a wineformats
> vs. vinoXML issue.
I don't take it as one vs. the other. But it would be nice if there
would only be one :-) .
> They are trying to solve different problems and for
> different users. Microformats are for humans first, machines second.
> XML (and vinoXML) are for machines first, humans second.
Again does this mean that one have to have two formats or does it mean
that some more work is done that a normal user can make use of the
document format.
A user does not look at raw html, he only looks at it through a browser
or some other tool which translates it for him. vinoXML should in its
pure form never be shown to a user, however one could use a Cascading
Style Sheet (CSS) to present it to the user. The user would always use
some type of application to enter the data and be guided to only enter
valid information.
> Should a
> blogger who simply wants to write up a tasting note with meaningful
> semantics be required to understand the vinoXML schema? Do they have to
> write their tasting note twice (once in HTML and once in vinoXML)? Now
> if we're talking about two wine-related applications/services that want
> to exchange wine data, I think vinoXML is a great match.
>
You see I am not convinced that one needs two formats for that as there
are many tools to transform XML - also I just use/know the tools I need
for my application which is written in Python.
I don't have a blog, so I am on thin ice here.
Quote from one of your posts:
Here's an example from a tasting note from my personal blog.
<h2 class=”item wine“>
<span class=”fn“>
<span class=”vintage“>2003</span>
<span class=”producer“>Scott Harvey</span>
<span class=”designation“>Mountain Selection</span>
<span class=”varietal“>Zinfandel</span>
<span class=”region“>Amador County</span>
</span>
<span class=”country“>USA</span>
<abbr class=”alcohol” title=”14.5″>14.5%</abbr>
</h2>
endQuote
How do you enter this into your blog? What tool does one use?
Could such a tool not be thought to deal with something like the
following?
Following is a portion from a vinoXML instance file:
<wine>
<name>Goldwater Eslin</name>
<additionalname>Merlot</additionalname>
<variety/>
<vintage>
<year>1999</year>
<bottle>
<size>750ml</size>
<price>
<pricetype>lastpurchasePrice</pricetype>
<currencycode>EUR</currencycode>
<pricevalue>25.00</pricevalue>
</price>
<apogee>
<firstyear>2003</firstyear>
<bestyear>2004</bestyear>
<pastyear>2009</pastyear>
</apogee>
<sealtype>cork</sealtype>
<tasting>
<tastedby>Wine Spectator</tastedby>
<tastedon>2000-11-15</tastedon>
<points>90.0</points>
<notes>Supple and generous, a remarkably graceful wine that
frames it's berry, spice, peppermint and chocolate flavours with
elegance, letting the flavours ring true on the lengthy finish. Tannins
are fine and beautifully integrated. Drink now through 2009.</notes>
</tasting>
</bottle>
</vintage>
</wine>
> Regarding parsing microformats, this is not sophisticated at all.
> Microformats build upon the most widely used markup spec in use today
> (HTML) and there are parsers available in several programming
> languages. In addition, microformat-aware email programs and browser
> plugins are starting to emerge that will allow end-users to use the
> information embedded in web pages and RSS feeds in meaningful ways.
>
I am not worried about the "basic" parsing of the html, this is the
same as xml, but the "content" parsing. I.e. is there a way with
Microformats to ensure that e.g. "vintage" is always "vintage" and not
sometimes "Jahrgang" or "millesime" or worse a little misspelled.
With vinoXML and The Wine Cellar Book one user uses the German GUI and
sees "Jahrgang" and he exports to vinoXML and a user using the English
GUI imports the file and will see this in "Vintage", if there is a
problem with e.g. "Wine Region" then this is named accordingly etc etc.
I am not saying with vinoXML this is all automatic, if a user would
want to look at a vinoXML file with e.g. browser someone would have to
sit down and do the work using the appropriate tools to generate
probably some CSS and/or some other xml to html transformation code.
> ...
>
> I think vinoXML will be useful to those of us who are developing
> software for the wine industry but I think wineformats are more useful
> to publishers of wine content (bloggers, winery site developers, wine
> event publishers, wine communities, and so on).
>
I look at vinoXML as the format to transmit information from one user
to another user and each user should be able to use the tool of his
preference and be able to publish to a blog, a wine site, to
import/export from his cellar book etc etc. Is it possible, I think
so, but frankly I do not know, nor do I have the know how to sit down
and create something so a blogger can sit down and write a wine tasting
note.
Don't misunderstand me, I can accept that maybe another format to
transmit the data is necessary but at this point I am not convinced.
Best regards
Werner
juice...@gmail.com
ja...@scrugy.com wrote:
> Within Scrugy I have established the following general rules when it
> comes to the elements of a wine name:
>
> Vintage (optional): Interpreted as non-vintage when missing.
>
> Producer/winery name (required): Can take the form of the winery's full
> name or what I call the short name (e.g. short name for "Miner Family
> Vineyards" is "Miner").
>
> Varietal (optional*): Chardonnay, Merlot, Pinot Noir, and so on. More
> of a new world naming element but starting to become more common in old
> world regions.
>
> Region/appellation (optional*): Napa Valley, Burgundy, Chianti, and so
> on.
>
> Designation (optional*): represents the label designation (e.g.
> "Oracle" for Miner's red blend). Unofficial but accepted "styles" such
> as White Zin and Meritage can fall in here too.
>
> Vineyard (optional): represents a vineyard designation such as "Garys'
> Vineyard" or "Ornato" from the Barolo example above)
>
> * = at least one of these 3 elements is required
>
> Thoughts? Are there holes in this approach? Any interest in factoring
> this out as a meta rule of some sort to serve as a guideline for a wine
> review microformat?
I think a meta-rule for wineformat may or may not be necessary (unless
I'm not thinking 'meta rule' with the right definition). What you
wrote here seems to cover it pretty well for version 1.0. Again,
falling back on "translate WS into a web standard" and keeping this
simple yet valuable, this would work for their French wines' as well as
their CA wines' reviews.
This is great. I think we're moving along here. Keeping the objective
of making everyone's review as authoritative a WS review and liberate
the wine world. :^)
The XML schema is news to me. I'm going to look into that a bit. Any
more thoughts on that?
Jason Coleman
juice...@gmail.com
I think you're right on. The problem is the
influence a small number of wine enthusiasts have over the entire wine
market. While "Wine Dictator" is tongue-in-cheek, it kind of isn't.
Its a
company of less than 100 people ( I think) that wields ENORMOUS power
over the entire market.
Standardizing how tasting notes are represented are a start...then its
going to depend on whats done with the information.
ja...@scrugy.com
> You raise a great point about the lack of a standard identifier for wines.
> Because there is no central repository of wine information, every company
> that builds a database is very protective of the data they have. This is
> reasonable, as they've probably spent a lot of time and money building that
> database. The DB has become, in effect, a competitive advantage.
I agree. IMO, a reason why this traditional line of thinking breaks
down on many web 2.0 sites is that the content in those databases is
user-generated. Of course these sites are providing a platform for
people to share and exchange ideas but those databases would be empty
if it weren't for the users contributing to them.
> However, these "walled gardens" of data are bad for consumers and bad for
> the industry. I want to make it as easy as possible for aspiring developers
> and wine enthusiast to make applications like WineLog and Scrugy. At first
> thought, this might seem to make bad business sense, but this kind of
> "democratization of data" is bound to happen anyway. It's better to be
> involved in its development than ignore it.
Beautifully put.