hCard Extract :: Explanation

Explanation

Intention

The intention of the Application is to prove that Microformats are a powerfull enough technology to:

• support structured searches from within the context of a set of web pages.
• allow being accessed and queried by intelligent agents.

The Application is not intended as a Production or Mass market Application. It is understood that under today's current technological environment sending an on-demmand User agent to multiple URLs to provide an inmediate response for a Mass market App is not feasible nor desirable. Querying an Aggregator of Microformats data being the suggested course of action today.

As a by product, the app shows that the underlying technologies of the web (URLs, HTTP, HTML) are powerfull enough to support a distributed database-like behaviour. This is possible as long as the data contained in the web page has some sort of meaningfull structure (Microformats being the technology for providing meaningfull structure within the context of a web page) and the location of the data is meaningfully stated (semantically meaningfull URLs being a possible technology for this). I'm not suggesting that this is the path the web will or should take. I'm just saying that it is technically possible. I do understand that today's technological limitations constraint current deployment yet it becomes an interesting concept when thinking long term ( doesn't it? :-) ).

How it works.

1. The User provides a set of URLs that contain hCards and search criteria to contrast with them.
2. The app fetches the web pages from the URLs provided and extracts the hCards that exist within them.
3. The app transforms the hCards properties data to UTF-8.
4. The app contrasts the found hCards with the search criteria provided.
5. The app returns an HTML fragment with the matching results which is then displayed in the App GUI.

Searching and Matching

• If no Search Criteria is provided, all hCards found are considered to be positive matches.
• If more than one Search Criteria is stated, only hCards that comply to all the Search criteria statements are considered a positive match.

• Searching matches the Search Value Substring within the Property Value String. Spaces are considered. Searches are Case Insensitive.

  For example:
  • Search Value: 'abc'
  • Search Value: 'eFg'
  • Search Value: 'hIJ'
  will provide a positive match for the following property value:
  • Property Value: 'abcdefghij klmnop'
  But:
  • Search Value: 'hijklm'
  will not.
• Name is contrasted against the following hCard n subproperties: fn, given-name, additional-name, family-name
• Given Name is contrasted against the following hCard n subproperty: given-name
• Family Name is contrasted against the following hCard n subproperty: family-name
• Address is contrasted against the following hCard adr subproperties: street-address, region, locality, postal-code
• Street Address is contrasted against the following hCard adr subproperty: street-address
• Locality is contrasted against the following hCard adr subproperty: locality
• Region is contrasted against the following hCard adr subproperty: region
• Postal Code is contrasted against the following hCard adr subproperty: postal-code
• For Name and Address, the app will provide a positive match if the string fragment provided is found within one the properties alone but not if the string fragment provided is found within a combination of properties. ie, in the following example: <div class="n"> <span class="given-name">Emiliano</span> <span class="fn"><span class="additional-name">Leandro</span> <span class="family-name">Martínez Luque</span></span> </div> possitive matches will be provided for:
  • Name: 'Emiliano'
  • Name: 'Martínez Lu'
  • Name: 'andro'
  • Given Name: 'Emil'
  • Familiy Name: 'nez Lu'
  It will not provide positive matches for:
  • Name: 'Emiliano Leandro'
  Since none of the hCard properties has that substring within it's value. (Property: fn has value 'Leandro Martínez Luque' in the above example)

Limitations and known issues.

• There is no validation of the data provided or found on the hCards (will fix soon).
• The parser can extract an hCard even if the containing document is not valid HTML. However the hCard fragment should comply to valid hCard syntax for appropiate finding. ( The parser is constructed to best comply to the excellent hCard Parsing guide, provided here and based on the hCard examples provided here ).
• The parser is constructed so that some invalid markup is accepted within the hCard fragment. However, results may vary for invalid HTML within hCards.
• The parser does not extract the following hCard properties: prodid, agent, rev, key, UID
• If property: agent exists within the hCard it may affect the overall values of the hCard being extracted
• The parser does not properly identify values of type: Object for properties: photo, logo
• A badly constructed hCard might affect the finding of other hCards within a document.
• Some charsets are not supported.
• The Parser might misunderstand the charset of a web page if not explicitly stated. (It does not recognize UTF-8 as default for XHTML 1.1, HTTP Headers take precedence over Document type declarations or Meta http-equiv)
• Some issues may exist with Spaces while matching since some space normalization is done when parsing multi node values.
• Some issues may exist with case matching for non ASCII characters. (The known UTF-8 string matching problems within php. (I'm using pregs, I think I should use multibyte eregs))
• Multi-value hCard properties are extracted if explicitly marked up or if they are marked up in an ordered or unordered HTML list but not if they are marked up as sub nodes of an explicitly marked up node. IE: The following examples will be picked up by the parser: <span class="multi-value-property-name">Value</span> <span class="multi-value-property-name">Another value</span> <ul class="multi-value-property-name"> <li>Value</li> <li>Another <strong>Value</strong></li> </ul> the following will not: <span class="multi-value-property-name"> <span>Value</span> <span>Another Value</span> </span>

Please send bug reports, corrections or suggestions: Contact me

If you are interested in Microformats, visit www.microformats.org for more information.
Data wants to be Procesable.