- From: Takeshi Kanai via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Feb 2017 05:38:18 +0000
- To: public-annotation@w3.org
@BigBlueHat No, I'm talking about Selector Fragment Identifier only. We can "identify" a text on a Web page with both Selector Fragment Identifier with Text Quote Selector (IRI-Alice) and Selector Fragment Identifier with Text Position Selector (IRI-Bob), for example. Then the question was do we need to call the text with its name (Alice, Bob)? If Selector Fragment Identifier is to be used to get to the text, I think it should be called with its location or address which tells us where the text is, rather than its name. It means both Alice's address and Bob's address should be used for that purpose. This is a valid Selector Fragment Identifier. `http://jp.example.org/page1#selector(type=TextQuoteSelector,exact=ペンを,prefix=私は、,suffix=持っています)` Unfortunately, this is invalid as URL. To use this string as URL, we have to encode the Japanese text. Then, the string of IRI and the string of URL are not identical. If these two were identical, I had no concerns. This is why I would like to clarify whether the given sting is "name" (Identifier, IRI) or "address" (Location, URL). I could say the IRI based spec, Selector Fragment Identifier describes how to name fragments on Web. Thanks to the IRI to URL conversion method, we can get to the fragments. It is very capable and I like it. On the other hand, I'm afraid that the original intention of Selector Fragment Identifier might be to provide means to describe location of fragments. If so, I think Selector Fragment Identifier should reform its basement from IRI to URL. Then this note will not need to open pandora's box. What do you think? -- GitHub Notification of comment by tkanai Please view or discuss this issue at https://github.com/w3c/web-annotation/pull/400#issuecomment-276576977 using your GitHub account
Received on Wednesday, 1 February 2017 05:38:24 UTC