Re: Suggestion for Microdata to RDF conversion

Hi Ian,

Thanks for the reply. No worries, I'll find a workaround/post-processing
step to make Microdata work intuitively in RDF environments (something
similar to applying the OWL axioms, but probably controlled by parser 
users so that OWL machinery isn't needed).

It probably makes sense to keep the core spec as-is. It's fine to close
this thread now and move on. I'll stay in touch with Philip to compare 
our implementations.

Regarding RDF, there is a lot to gain from using it on the infrastructure
level, even w/o OWL. RDF + SPARQL is comparable to HTML + DOM. In that 
comparison, OWL would then perhaps be a fancy AJAX toolkit, a CMS, or 
a powerful browser plugin. The low-level standards make the difference
(and the network effects), there is more flexibility on the higher 
levels, standards-wise.


Benjamin Nowack

On 28.01.2010 01:03:53, Ian Hickson wrote:
>On Fri, 22 Jan 2010, Benjamin Nowack wrote:
>> Here is one that'd be RDF:
>>    <div itemscope itemtype="">
>>       <span itemprop="x"/>
>>       <span itemprop=""/>
>>    </div>
>> Assuming that empty values make sense, the two properties would result 
>> in the same predicate URI: because "x" (per 
>> spec wording) is from the same vocabulary as 
>>, and "" is a 
>> full URI, which happens to be from the same vocab, too.
>I think this is a really bad idea. I don't think we want to end up in a 
>situation where people using microdata have to check two (or more) 
>properties for each conceptual property, just in case it was serialised by 
>a tool that used different conventions -- one of the really big design 
>goals of microdata is for there to be a single way to get data out, to 
>make data extraction as easy as possible.
>> It's fine to have 2 distinct properties in the Microdata model including 
>> the DOM API, but effectively just one in RDF.
>I disagree. I think that would be a design failure.
>> The RDF model differs in other situations, too (graph vs. tree etc).
>The graph vs tree issue is not a fundamental limitation of microdata; I 
>expect we'll add tree support in a future version.
>> If the 2 models were identical, there wouldn't have been a need for 
>> Microdata in the first place.
>On the contrary; microdata is needed precisely because the RDF model 
>didn't have a simple and easy-to-use serialisation format in HTML.
>> It would of course be possible to mandate that URI-based itemprops MUST 
>> NOT be from the same vocabulary specified by the itemtype. This would be 
>> intuitive as URI-based itemprops are meant to enable vocab mixing. It 
>> doesn't make too much sense to specify a context vocabulary and still 
>> use fully qualified itemprop URLs.
>We could do that, but it would be very confusing that you could 
>copy-and-paste some properties from one page to another and have it stop 
>being valid because you _added_ information (the itemtype).
>> Well, ... ;) RDF is RDF, and OWL is OWL. Even if certain OWL axioms can 
>> be written in simple RDF blobs, this doesn't mean that evaluating these 
>> definitions is equally simple. You need an inference engine or at least 
>> a SPARQL processor with UPDATE functionality. The overlap between people 
>> who use RDF as a data integration mechanism and those who run OWL 
>> engines is pretty small. Have a look at [1], you can find communities 
>> for each colour, some overlap, some don't. I've created dozens of RDF 
>> apps, I can't remember when I last required OWL.
>I can't imagine any reason to use something as complicated as RDF if 
>you're going to not use the main thing that makes it interesting! :-)
>Seems to me that if you're just using RDF as an opaque data store, you 
>might as well just use a custom mechanism. It's not clear what you would 
>gain from using RDF.
>Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>       U+263A                /,   _.. \   _\  ;`._ ,.
>Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 28 January 2010 08:07:16 UTC