Re: The harm that can come if the W3C supports publication of competing specs

Philip Jägenstedt wrote:
> On Sun, 17 Jan 2010 10:27:00 +0100, Graham Klyne <GK@ninebynine.org> wrote:
> 
>> Having skimmed the messages in this thread to date, I feel the focus 
>> on *browser* implementations is ignoring wider concerns of non-browser 
>> applications that consume the embedded data, and that the focus on 
>> syntax is distracting from what really matters, the underlying 
>> semantic model.
> 
> I agree that browsers will be minority consumers of microdata, but also 
> feel that by having a model that is possible to write good DOM APIs for 
> which are possible (desirable rather) to implement in browsers, the 
> metadata becomes much more useful (likely to be used) by others than the 
> traditional semantic web community. 

No argument so far (for some value of "good", of course).

> ... Since the RDF model is a graph, it 
> is hard to see how it could be represented using HTMLCollection-like 
> interfaces (you would need a query language for it to be useful) or 
> mapped to JavaScript (you can construct the objects with some effort, 
> but can't serialize them as JSON if the graph has loops).

Hmmm... I'm not sure I fully follow this.  But turning it around, RDFquery [1] 
is an example of an API that extracts RDF data from RDFa in an HTML DOM.  I 
mention this as an existence proof, no more.

[1] http://code.google.com/p/rdfquery/

>> The mediawiki thread cited by Shelley notes that there is some 
>> ambiguity in the semantics of the microdata presentation, but that's 
>> relatively easily fixed, I think (just ensure the unqualified 
>> properties are mapped implicitly to a full URI, which in turn is 
>> described by an RDF schema or OWL).
> 
> If itemtype is not used, then the data has no semantics outside of the 
> page, and using it is as unsafe as e.g. scraping HTML tables. The RDF 
> extraction algorithm doesn't include untyped items, as it shouldn't. I 
> wouldn't really call this ambiguity, but possibly the spec could be more 
> explicit about this. In the extreme one could even require itemtype to 
> be used, but I think that would harm useful site-private use of microdata.

I would strongly prefer that local-only semantics were avoided, if possible. 
Things have a way of leaking out from the place in which they first appear. 
Maybe a "global" semantics could be attached to a URI that is derived from the 
URI of the containing page, or the in-scope base URI, if explicit typing is not 
provided.

>> So while I agree that it is very unfortunate that there are two 
>> competing proposals, I don't think it's fatal *provided* that there is 
>> a clear mapping to underlying common semantics.  In this case, RDF is 
>> firmly established in W3C as a semantic model for metadata, so I argue 
>> that all proposals should provide a clear mapping from their 
>> particular syntax to the RDF abstract syntax.  The existing semantics 
>> of RDF can take care of the rest.
> 
> I would agree, RDF is a well established model and there's nothing much 
> wrong with it. Presently, the only RDF concept I'm aware of that can't 
> be expressed using microdata is XML Schema Datatypes (XSD). I would 
> argue that the datatypes should defined in the vocabulary and not by the 
> author, so I consider this restriction quite sensible. This only seems 
> to matter if you're trying to embed RDF data verbatim which you have no 
> control over, in which case I would argue that you shouldn't bother with 
> either microdata or RDFa and simply link to an external N3/Turtle 
> representation. However, if a use case other than "express arbitrary 
> RDF" requires XSD, it certainly wouldn't be too late to add it to 
> microdata as itemproptype or something. (I would be interested in 
> hearing about such use cases.)

If we really must have two proposals, then in the case of Microdata, I'm not 
suggesting that it should be capable of representing arbitrary RDF, rather that 
any well-formed Microdata has a well-determined mapping to RDF.  So it's OK if 
you can't represent arbitrary datatyped values, for example.

RDFa, on the other hand, already provides for representation of arbitrary RDF. 
I still think its preferable to have a single spec that meets all requirements.

#g

Received on Sunday, 17 January 2010 15:17:53 UTC