W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

Re: Straw Poll (ISSUE-1)

From: Benjamin Nowack <bn@kasabi.com>
Date: Sat, 22 Oct 2011 17:24:42 +0200
Message-ID: <4EA2E03A.1030703@kasabi.com>
To: public-html-data-tf@w3.org
I would vote for :
* Processors by default don't generate triples for short itemprop names.
* Processors support a standard run-time configuration mechanism to use
   target namespaces for a set of itemtype patterns (maybe together with
   3b for defaults provided by the processor provider/creator).

This could solve issues like the old one around which vCard RDF 
namespace to use for parsing hcard or a microdata-encoded vcard. The 
processor users would (have to) decide themselves, e.g. via something like:

   microformats.org/profile/hcard => http://myhost/myvcardvocab#
   * => hashSlash


Jeni Tennison wrote:
> All,
> This is a quick straw poll to gauge feeling in the group about whether/how microdata processors generating RDF should use vocabulary knowledge to generate appropriate/useful RDF. The options are:
>   1. all processors use the same (default) mapping for all vocabularies
>   2. all processors use a default mapping for unknown vocabularies and a customised mapping for known vocabularies where the known vocabulary mappings are:
>      a. a pre-defined set of popular vocabularies
>      b. drawn from a registry
>      c. determined by resolving the vocabulary's schema
>   3. different processors have different sets of mappings and must specify how they are set
>      a. all processors have the same default mapping for unknown vocabularies
>      b. processors must also specify what default mapping they use
> Please indicate which option(s) you prefer and which you can't live with.
> I'll pull together results on Tuesday morning UK time.
> Cheers,
> Jeni

Benjamin Nowack
Software Engineer, Kasabi, Talis Systems Ltd


Talis Systems Ltd is registered in England and Wales as 07196440.
Received on Saturday, 22 October 2011 15:25:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:25 UTC