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

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.


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).



> 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 microdata spec should not be arbitrarily different from the RDFa
spec.  The URIs generated should work with RDF.

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.
Or microformats but they might not want to serve RDF schemas.



> 
> 
>>> It makes W3C responsible for supporting things added in 
>>> microformats.org which, while W3c may need to do this special cases 
>>> should not be built into the semantics of the HTML language.
> 
> There is no effort needed on the W3C side for this at all. If the W3C 
> would rather not be part of this though I'm happy to change the URL.
> 
> 
>>> 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.


> 
> If the URL syntax allowed the # character in a fragment identifier, we 
> could avoid escaping the second one; would that help?

No.

Tim

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