Re: Re http://www.w3.org/2001/tag/group/track/actions/510

On Mon, 27 Jun 2011, Tim Berners-Lee wrote:
> On 2011-05 -26, at 01:20, Ian Hickson wrote:
> > On Fri, 20 May 2011, Tim Berners-Lee wrote:
> >>> 
> >>> http://dev.w3.org/html5/md/#examples
> >>> 
> >>> In the example, the HCARD data is to be parsed to produce RDF data 
> >>> with a predicate whose URI is 
> >>> http://www.w3.org/1999/xhtml/microdata#http://microformats.org/profile/hcard%23:adr
> >>> 
> >>> That is an appalling URI, for a number of reasons.
> >>> 
> >>> 1. It is horribly long
> > 
> > It's opaque and not intended for human consumption, so that doesn't 
> > seem like a serious problem.
> 
> URIs are, of course, seen by humans in fact in many cases even though to 
> first order a web browsing person should not see any.
> 
> A developer or a data analyst writing a SPARQL query 
> like 
> 	select * where { ?who <http://www.w3.org/1999/xhtml/microdata#http://microformats.org/profile/hcard%23:adr > ?where }
> 
> is not going to be so.

Sure. You wouldn't do that. You'd use a human-readable URL, which you 
define to be equivalent to the microdata ones.

See, for instance, how the "work" vocabulary defines this:

http://www.whatwg.org/specs/web-apps/current-work/complete.html#conversion-to-rdf


> Remember that there is while the HTML code for a web page is rather 
> cumbersome to look at compared the page, if you extract the data and 
> serialize it as turtle it often looks pretty easy for the advanced user 
> to understand.  (Say the same level of user as one who can handle 
> spreadsheets).

Realistically, I don't expect most people to do this, even those who 
author microdata. They'll write their documents, test it with a preview 
tool like Google's Rich Snippets Testing Tool, and be on their way:

   http://www.google.com/webmasters/tools/richsnippets

Similarly, on the consuming side, it's all automated, no humans involved.

As far as I can tell, this is the case for all the use cases for which you 
might theoretically use an RDF store with microdata input.

Are there compelling use cases where that isn't the case?

   
> >>> 2. It is constructed including two other URIS, so that there is a 
> >>> combination of two authorities, so it will only be supported if the 
> >>> w3.org and microformats.org sites coordinate the generation of new 
> >>> microformats.
> > 
> > Actually the W3C part of the URI is fixed and used for all microdata 
> > vocabularies, so the w3.org site doesn't have to be involved in the 
> > development of the vocabulary at all. I'm happy to use another URL if 
> > you would like; I used that one for consistency with e.g. the 
> > URLification of the rel="" values in RDFa. It could be a whatwg.org 
> > URL or even a separate scheme altogether. The latter would also reduce 
> > your issue #1 above about length.
> 
> [...] The URIs generated should work with RDF.

That seems to be a non-sequitur. I'm not aware of anything not working 
with RDF here.


> The microdata spec should not be arbitrarily different from the RDFa 
> spec.

It's not arbitarily different. It's completely different, for very good 
and carefully-deliberated reasons.


> Yes, a shorter URI which is in the w3.org space and then has a hash 
> followed by the localname could work, effectively a default namespace 
> hosted by w3c, who would support it on the web.

The URLs are opaque, there's nothing to host.

However, if you would like the "http://www.w3.org/1999/xhtml/microdata#" 
part changed to something else within the w3.org space, please let me know 
what to change it to. If you would like it changed to something outside 
the w3.org space, let me know also, and I'll find an alternative. Ideally 
we'd just use a new scheme, e.g. "md:" or some such. I mostly haven't done 
so because I'm concerned people might then try to do something with the 
scheme, which would cause no end of confusion.


> Or microformats but they might not want to serve RDF schemas.

Not sure what you're referring to here.


> >>> 3. Because it has a hash in he middle instead of at the end, typical 
> >>> serializers won't be able to use namespace prefix on output, so any 
> >>> files which use these URLs will by ugly, unreadable, and large.
> > 
> > I don't understand this issue. Could you elaborate?
> 
> Serializers use namespaces to make the output compact and readable.
> They typically use N3/turtle prefixes or XML namespaces as abbreviations 
> where the hash or if none the last slash is taken as the end of the 
> namespace URI, and everything from then on must be basically a 
> localname.

I don't really see what the problem is here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 8 July 2011 00:30:46 UTC