Re: Suggestion for Microdata to RDF conversion

On Fri, 22 Jan 2010, Benjamin Nowack wrote:
> 
> Here is one that'd be RDF:
> 
>    <div itemscope itemtype="http://example.com/vocab#Example">
>       <span itemprop="x"/>
>       <span itemprop="http://example.com/vocab#x"/>
>    </div>
> 
> Assuming that empty values make sense, the two properties would result 
> in the same predicate URI: http://example.com/vocab#x because "x" (per 
> spec wording) is from the same vocabulary as 
> http://example.com/vocab#Example, and "http://example.com/vocab#x" is a 
> full URI, which happens to be from the same vocab, too.

Ok.

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
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 28 January 2010 01:04:28 UTC