12 ms·

Microdata: HTML5’s Best-Kept Secret

59 points by pathik 16y ago

dododo 16y ago
why bother? because google, for example, will use some of the annotations: http://www.google.com/support/webmasters/bin/answer.py?answer=99170 http://www.google.com/support/webmasters/bin/answer.py?answe...
- akozak 16y ago
  Like I've mentioned before, Google and browser support are hardly the limit of how annotations would be useful. Having a scalable standard for metadata would create a platform for all types of services. To me, what's exciting isn't what it will immediately get you, but what will be possible with that platform of data when it's a well-accepted standard.
  - chbarts 16y ago
    > Like I've mentioned before, Google and browser support are hardly the limit of how annotations would be useful. But they're the only reasons anyone would use them NOW.
Kilimanjaro 16y ago
Polluting markup is not the solution. It looks really ugly and makes maintenance a nightmare. Separate markup from data (and style, scripts, etc) for a cleaner app. I've always been a proponent of placing all data in a script using json which you can consume easily without screen scraping. http://mylittlehacks.appspot.com/dataislands http://mylittlehacks.appspot.com/dataislands
- TrevorFancher 16y ago
  I don't see microdata as markup pollution. It is semantic information that is closely tied to the data it is representing. Rather than just telling the browser you have a paragraph, you can tell it the paragraph contains an address. And it seems to me that in real world web apps all the markup with microdata could be programmtically added. Create a new object with a microdata schema and get an ORM type object with an HTML write method. This way you never manually type microdata markup anyways.
  - henrikschroder 16y ago
    Turning <div> <h1>Hendershot's Coffee Bar</h1> <p>1560 Oglethorpe Ave, Athens, GA</p> </div> Into <div itemscope itemtype="http://data-vocabulary.org/Organization"> <h1 itemprop="name">Hendershot's Coffee Bar</h1> <p itemprop="address" itemscope itemtype="http://data-vocabulary.org/Address"> <span itemprop="street-address">1560 Oglethorpe Ave</span>, <span itemprop="locality">Athens</span>, <span itemprop="region">GA</span>. </p> </div> ...is not markup pollution? It's three times as big as before, and the value of this is still questionable.
    - jacobolus 16y ago
      It’s mostly intended for places where data is going to be slurped out of a database and dumped into a template or renderer. Adding a bit of extra gunk to the template isn’t the end of the world (especially if you have a sane template system). If I’m writing some text by hand, I’m going to use markdown and just write: # Hendershot’s Coffee Bar 1560 Oglethorpe Ave, Athens, GA As for the benefits: having some widely-used machine-readable metadata linked directly to the data could let browsers do some pretty neat stuff in the future, like letting a user click to add an event to his calendar, look up directions to an address, or add a person to his contact book.
      - dctoedt 16y ago
        Kilimanjaro's JSON data-island example is certainly more readable. OTOH, with that approach there's the risk that, during maintenance, the data island will be overlooked and will become inconsistent with the human-readable information. Edit: Perhaps that risk could be mitigated by having the human-readable markup issue a JS call to the data island, which would have the benefit of being DRY-compliant.
    - what 16y ago
      But it's smaller than the proposed data island. <script data> bizcard={ name: 'Hendershot's Coffee Bar', address :{ line :'1560 Oglethorpe Ave', city :'Athens', state :'GA', zipcode:'30606', country:'US' } }; </script> <div> <h3><span data="bizcard.fname"></span></h1> <span data="bizcard.address.line"></span> <span data="bizcard.address.city"></span> <span data="bizcard.address.state"></span> </div> Which also won't work for people with javascript disabled. Plus, does Google go through your javascript and figure out what eventually makes it onto the page?
- Kilimanjaro 16y ago
  Another option would be to put all data in a separate file and reference it with a link tag, just like rss/atom. Then from the markup we could use a 'ref' attribute to reference it. Zero pollution Zero overhead Markup/style/data separation
  - Qz 16y ago
    Part of the dilemma, I think, is that in the age of Google, everything except the markup IS data (and in some cases the markup is data too).
arfrank 16y ago
Recent discussion here about microdata: http://news.ycombinator.com/item?id=1673623 http://news.ycombinator.com/item?id=1673623
deleted 16y ago
[deleted]
alanh 16y ago
Never confuse microdata or microformats for API substitutes.
mark_l_watson 16y ago
I have always liked (and often written about) an alternative: for HTML: http://example.com/test.html http://example.com/test.html, for semantic data: http://example.com/test.n3 http://example.com/test.n3 (N3 RDF format). If a web app creates dynamic data at URL: http://example.com/stockfeeds?symbol=APPL http://example.com/stockfeeds?symbol=APPL then perhaps use something like: http://example.com/stockfeeds.n3?symbol=APPL http://example.com/stockfeeds.n3?symbol=APPL to get RDF. Also, have standard (or commonly used) meta data to point to an equivalent RDF URI in generated HTML.

59 points by pathik 16y ago

why bother? because google, for example, will use some of the annotations: http://www.google.com/support/webmasters/bin/answer.py?answer=99170 http://www.google.com/support/webmasters/bin/answer.py?answe...

akozak 16y ago
Like I've mentioned before, Google and browser support are hardly the limit of how annotations would be useful. Having a scalable standard for metadata would create a platform for all types of services. To me, what's exciting isn't what it will immediately get you, but what will be possible with that platform of data when it's a well-accepted standard.
- chbarts 16y ago
  > Like I've mentioned before, Google and browser support are hardly the limit of how annotations would be useful. But they're the only reasons anyone would use them NOW.

Kilimanjaro 16y ago

Polluting markup is not the solution. It looks really ugly and makes maintenance a nightmare. Separate markup from data (and style, scripts, etc) for a cleaner app. I've always been a proponent of placing all data in a script using json which you can consume easily without screen scraping. http://mylittlehacks.appspot.com/dataislands http://mylittlehacks.appspot.com/dataislands

TrevorFancher 16y ago
I don't see microdata as markup pollution. It is semantic information that is closely tied to the data it is representing. Rather than just telling the browser you have a paragraph, you can tell it the paragraph contains an address. And it seems to me that in real world web apps all the markup with microdata could be programmtically added. Create a new object with a microdata schema and get an ORM type object with an HTML write method. This way you never manually type microdata markup anyways.
- henrikschroder 16y ago
  Turning <div> <h1>Hendershot's Coffee Bar</h1> <p>1560 Oglethorpe Ave, Athens, GA</p> </div> Into <div itemscope itemtype="http://data-vocabulary.org/Organization"> <h1 itemprop="name">Hendershot's Coffee Bar</h1> <p itemprop="address" itemscope itemtype="http://data-vocabulary.org/Address"> <span itemprop="street-address">1560 Oglethorpe Ave</span>, <span itemprop="locality">Athens</span>, <span itemprop="region">GA</span>. </p> </div> ...is not markup pollution? It's three times as big as before, and the value of this is still questionable.
  - jacobolus 16y ago
    It’s mostly intended for places where data is going to be slurped out of a database and dumped into a template or renderer. Adding a bit of extra gunk to the template isn’t the end of the world (especially if you have a sane template system). If I’m writing some text by hand, I’m going to use markdown and just write: # Hendershot’s Coffee Bar 1560 Oglethorpe Ave, Athens, GA As for the benefits: having some widely-used machine-readable metadata linked directly to the data could let browsers do some pretty neat stuff in the future, like letting a user click to add an event to his calendar, look up directions to an address, or add a person to his contact book.
    - dctoedt 16y ago
      Kilimanjaro's JSON data-island example is certainly more readable. OTOH, with that approach there's the risk that, during maintenance, the data island will be overlooked and will become inconsistent with the human-readable information. Edit: Perhaps that risk could be mitigated by having the human-readable markup issue a JS call to the data island, which would have the benefit of being DRY-compliant.
  - what 16y ago
    But it's smaller than the proposed data island. <script data> bizcard={ name: 'Hendershot's Coffee Bar', address :{ line :'1560 Oglethorpe Ave', city :'Athens', state :'GA', zipcode:'30606', country:'US' } }; </script> <div> <h3><span data="bizcard.fname"></span></h1> <span data="bizcard.address.line"></span> <span data="bizcard.address.city"></span> <span data="bizcard.address.state"></span> </div> Which also won't work for people with javascript disabled. Plus, does Google go through your javascript and figure out what eventually makes it onto the page?
Kilimanjaro 16y ago
Another option would be to put all data in a separate file and reference it with a link tag, just like rss/atom. Then from the markup we could use a 'ref' attribute to reference it. Zero pollution Zero overhead Markup/style/data separation
- Qz 16y ago
  Part of the dilemma, I think, is that in the age of Google, everything except the markup IS data (and in some cases the markup is data too).

arfrank 16y ago

Recent discussion here about microdata: http://news.ycombinator.com/item?id=1673623 http://news.ycombinator.com/item?id=1673623

deleted 16y ago

[deleted]

alanh 16y ago

Never confuse microdata or microformats for API substitutes.

mark_l_watson 16y ago

I have always liked (and often written about) an alternative: for HTML: http://example.com/test.html http://example.com/test.html, for semantic data: http://example.com/test.n3 http://example.com/test.n3 (N3 RDF format). If a web app creates dynamic data at URL: http://example.com/stockfeeds?symbol=APPL http://example.com/stockfeeds?symbol=APPL then perhaps use something like: http://example.com/stockfeeds.n3?symbol=APPL http://example.com/stockfeeds.n3?symbol=APPL to get RDF. Also, have standard (or commonly used) meta data to point to an equivalent RDF URI in generated HTML.