Re: Multiple itemtypes in microdata

All,

I think this discussion is coming dangerously close to religious war territory and I don't want us to get side-tracked from what we need to do, which is write up guidelines for publishers and consumers about how to publish and consume data embedded in HTML.

Let's try to stay focused, please.

With that in mind:

On 19 Oct 2011, at 02:13, Gregg Kellogg wrote:
> On Oct 18, 2011, at 5:00 PM, Ian Hickson wrote:
> Yes, an application will have to process the data in a meaningful way for that application. For example, the Structured Data Linter (http://linter.structured-data.org) processes a variety of data just to make snippets (intended to give authors some idea of what their markup might look like in a hypothetical result page).

I've started to pull together lists of generic and vocabulary-aware parsers/validators etc at:

  http://www.w3.org/wiki/Choosing_an_HTML_Data_Format#Good_Publishing_Practice

Could you add to the list any tools such as the Structured Data Linter which help users to check that their markup works as anticipated?

> Music software, such as Seevl performs music discovery using data marked up with Music Ontology and schema.org.

Would someone volunteer to write-up Seevl as a use case?

>> The properties in the microdata vCard vocabulary aren't URLs, and it would 
>> be incorrect to treat them as URLs. They are "defined property names" in 
>> the sense defined in the HTML specification.
>> 
>> This has implications. For example, it would be invalid to treat these two 
>> microdata fragments as equivalent in any way:
>> 
>>  <address itemscope itemtype="http://microformats.org/profile/hcard">
>>   Written by
>>   <span itemprop="fn">
>>    <span itemprop="n" itemscope>
>>     <span itemprop="given-name">Jill</span>
>>     <span itemprop="family-name">Darpa</span>
>>    </span>
>>   </span>
>>  </address>
>> 
>>  <address itemscope itemtype="http://microformats.org/profile/hcard">
>>   Written by
>>   <span itemprop="http://microformats.org/profile/hcard#fn">
>>    <span itemprop="http://microformats.org/profile/hcard#n" itemscope>
>>     <span itemprop="http://microformats.org/profile/hcard#n/given-name">Jill</span>
>>     <span itemprop="http://microformats.org/profile/hcard#n/family-name">Darpa</span>
>>    </span>
>>   </span>
>>  </address>
> 
> Within the context of the HTML definition of that vocabulary, you're correct. By definition, _given-name_ only has meaning within the context of _n_. With an RDFS representation of the vocabulary, even if _n_ and _given-name_ are placed in a flat namespace, the validity of applying each to a given object can be determined given appropriate RDFS domain/range definitions and type inference of the object _n_ references. OWL2 allows even more specificity, including the fact that you might have only a single value for _family-name_, but allow multiple for _given-name_.

This is all related to ISSUE-1, which is about how vocabulary-aware a microdata-to-RDF processor needs to be, and how it might become aware of a vocabulary.

We've talked about having a number of options for how URIs are created for defined property names. We can take from Hixie's description that one of the options should be similar to that given in the original microdata-to-RDF mapping. We also need to make vocabulary creators aware of the possible mappings and encourage them to document which mapping should be used with their vocabulary.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 19 October 2011 09:51:40 UTC