W3C home > Mailing lists > Public > www-tag@w3.org > August 2011

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

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Thu, 11 Aug 2011 21:13:41 -0400
Message-ID: <4E447E45.4040601@arcanedomain.com>
To: TAG Member List <tag@w3.org>
CC: Sam Ruby <rubys@intertwingly.net>, Tim Berners-Lee <timbl@w3.org>, Ian Hickson <ian@hixie.ch>, TAG List <www-tag@w3.org>, Larry Masinter <masinter@adobe.com>, "Michael[tm] Smith" <mike@w3.org>
Re-mailing with TAG action references so Tracker will pick them up 
(ironically, the reference to the action URI in the subject doesn't do it, 
I think, only the syntax below.)  Anyway...

Tracker, this relates to TAG ACTION-510 and to ACTION-580.

BTW: Tim is indeed the person to ask, but my reading is: yes, removal of 
that section resolves the concern and renders the issue moot. Not sure 
whether I can find Tim before then, so I'll arrange for confirmation no 
later than the 13-15 Sept. TAG F2F.  Thank you.

Noah


On 8/11/2011 8:20 PM, Sam Ruby wrote:
> Does the following change sufficiently make the issue moot?
>
> http://html5.org/r/6427
>
> - Sam Ruby
>
> On 06/27/2011 10:50 AM, 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.
>>
>>
>> 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 <http://w3.org> and microformats.org
>>>>> <http://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 <http://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
>>> <http://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 <http://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 <http://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. `._.-(,_..'--(,_..'`-.;.'
>>>
>>
>
>
>
Received on Friday, 12 August 2011 01:14:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:39 GMT