Re: Selectors as URIs?

> On 13 Apr 2015, at 19:34 , Randall Leeds <randall@bleeds.info> wrote:
> 
> Why is it important to use a selector as a fragment.
> 
> I'm getting from this thread that the selectors are attractively flexible vs CFI (GREAT that's what we want) but not why the use case requires fragments in any way.
> 
> Is there a need to link to something from or to an environment where the selector cannot be communicated and handled separately by the viewer?

O.k., there is a need for somewhat more background detail here…

There is a current 'vision' to bring publishing (not only books, but all kinds of documents) and the more traditional Web closer together. Essentially, a document in epub seen/read in a browser or in a separate reader should be the same things and the choice should only be dictated by the user based on local circumstances. I do not want to bore you with the details, I just refer to a white paper we authored recently[1].

However, what this means is that the core Web (browser) approach to access a specific portion of a document, which is based on URI-s (including fragments) should be the fundamental approach. Cfi works for that, but barely, because it is bound to specificities of the current EPUB format; hence looking for possible replacements. And yes, as you say, the greater flexibilities offered by the selector model is also a major plus.

[1] http://w3c.github.io/epubweb/

> 
> If we get into fragments I just wonder whether we shouldn't be campaigning for an xpointer revival. Or maybe what I'm hearing is that ereaders are willing to support fragments that browser vendors won't touch.

See above: in this context let us not consider ereaders as separate animals. In future, they should be the same as browsers, albeit possibly with a different user interface.

So xpointer… yes. After all, what I have below

http://www.example.org/#selector(type=DataPositionSelector,start=4096,end=4104)

follows the same philosophy, very similar to the svg specific fragments defined by the SVG document.

> 
> If you know your environment can accommodate your favorite selectors, serialized in some known way, as URI fragments, there's nothing preventing you from doing so.
> 

Of course. But as a proper standards' person it would be good if the publishing community did not reinvent the wheel…

thanks

Ivan


> 
> On Mon, Apr 13, 2015, 10:07 Ivan Herman <ivan@w3.org> wrote:
> Hm. The problem is that there is a use case here that we may have to accommodate somehow.
> 
> At the moment, if you take an Ebook, and you want to have a URI identifying a specific position within a specific chapter of a book, what you can use something like:
> 
> http://www.example.org/book#epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/3:10)
> 
> which identifies a position within a paragraph within a chapter of the book inside an EPUB package. It uses the epubcfi[1] specification of IDPF, which specifies an EPUB specific fragment ID.
> 
> epubcfi works, and is used, but it has its drawbacks (let me not go into all the details). One drawback is that what it offers as anchoring possibility though powerful) is way less flexible than the selector model, primarily the range selectors. The conceptual model behind those would become useful, as an alternative to something like epubcfi, if those structures could be used as fragments. Maybe we have to restrict its usage and define it only for specific media types (text, etc) to avoid the issues in your example on genetic sequences or full blown graphics. But believe something like that would be very useful and, for some communities, necessary.
> 
> Cheers
> 
> Ivan
> 
> (b.t.w., I am not sure I understand your comment on RFC3986)
> 
> [1] http://www.idpf.org/epub/linking/cfi/epub-cfi.html
> 
> 
> > On 13 Apr 2015, at 18:28 , Robert Sanderson <azaroth42@gmail.com> wrote:
> >
> >
> > We discussed fragments in the community group at length.
> >
> > The concerns about the approach are documented here:
> >     http://www.w3.org/TR/annotation-model/#fragment-uris
> >
> > These boil down to the fact that as you get more sophisticated selections the URI becomes unbearably long.
> > Consider serializing an entire SVG document into the URI to specify a non rectangular area. Or selecting the previous and following 1024 Gs Cs As and Ts to select a range of text in a genetic sequence.
> >
> > My personal position is that selectors should not be turned into fragments, because (especially) that would break the rules of fragment identifiers as laid out in RFC 3986:
> >
> > The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource.
> > As further discussed by JeniT here:
> >     http://www.w3.org/TR/fragid-best-practices/
> >
> > Basically, unless there's a new text/HTML RFC that allows us to do it, we can't arbitrarily shove the description of the segment into its identity.
> >
> > Rob
> >
> >
> > On Mon, Apr 13, 2015 at 9:10 AM, Ivan Herman <ivan@w3.org> wrote:
> > (Although this may not be immediately relevant to the Working Group right now, I think the question *may* become relevant, hence my copy to it…)
> >
> > Rob, Paolo,
> >
> > a question came up at the Digital Publishing IG today. The IG is looking at general fragment identifiers for the purpose of identifying portions within a digital document (typically EPUB, but also some future versions of it). The Selector structure of the OA obviously gives a great model for various types of anchors, mainly when combined with other, existing fragment id definitions.
> >
> > However, at present, the selectors are defined in terms of RDF resources; to take an example from the spec, it says, for example
> >
> > selector": {
> >       "@id": "http://example.org/selector1",
> >       "@type": "oa:DataPositionSelector",
> >       "start": 4096,
> >       "end": 4104
> > }
> >
> > To be usable for a fragment identification, this structure should be turned into some sort of a, well, URI fragment. I mean, it is probably relatively easy to do this, something like
> >
> > http://www.example.org/#selector(type=DataPositionSelector,start=4096,end=4104)
> >
> > would do it but, of course, the ideal would be if that type of fragment format would be defined at one place.
> >
> > The question is: has this ever been discussed previously on the OA model? If it hasn't been done, should it be done? If it should be done, should it be done by this WG, or some other group?
> >
> > Thanks
> >
> > Ivan
> >
> >
> > ----
> > Ivan Herman, W3C
> > Digital Publishing Activity Lead
> > Home: http://www.w3.org/People/Ivan/
> > mobile: +31-641044153
> > ORCID ID: http://orcid.org/0000-0003-0782-2704
> >
> >
> >
> >
> >
> >
> >
> > --
> > Rob Sanderson
> > Information Standards Advocate
> > Digital Library Systems and Services
> > Stanford, CA 94305
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
> 
> 
> 
> 


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704