Make Selectors available for the wide world?

Guys,

(I was not sure whether I should put this as an issue on github, or have a discussion on the mailing list first. I decided to do the latter and, if we think there may be some interest in this, I will move it to github.)

Whatever I write is with my staff contact hat put down...

I always considered the Selector (and its subclasses) as very powerful. And that is good, we need that. It is so good that I also consider it as something whose importance goes beyond annotations (yes, there is a world beyond that:-). I can envisage other applications needing something similar. Actually, similar in two different ways: either as they are, as a description to select part of a resource; or to have a powerful fragment ID that can express the Selector concepts. The obvious example for the latter is RDF in general; while the current selector mechanism works well in a specific model like ours, in general RDF relies on using URI-s to identify something, meaning that it requires a suitable fragment URI. AFAIK, the EPUB version of the annotation model makes use, currently, of #epubcfi; maybe this is also something we can replace with selector URIs.

I was wondering whether we can do a minimal step to make this type of usage easier (if we agree with my assessment, of course). Here are some thoughts, not mutually exclusive:

1. Separate the Selectors' part into a separate namespace. The oa namespace would be used for what is really annotation specific, and we could have the "select" (or whatever) namespace for the Selector class and all its subclasses. This change would affect only the RDF part, obviously, as well as the json ld context file.
2. Separate the Selectors' section (essentially 4.2 in the current model document) into a document on its own. I believe that this is only really necessary for the JSON document (that we would produce), the RDF document can stay as it is if we also adopt #1 above (RDF people are used to using part of a vocabulary).
3. Define a fragment ID that reflects the current selectors.

I think that #1 and #2 are just minor editorial changes that we can do easily. The only downside of #1 is that it may be a strong departure from the Community Group document; I am not sure whether it is indeed a big issue.

#3 requires further work and it is actually on the borderline of whether it is part of our charter. (Although we did discuss something similar in conjunction with the FindText API.) We would have to see if something like the following is 'legal' to be registered as a fragment ID:

http://www.ex.org/ex.html#selector(type=TextQuoteSelector,exact="anotation",prefix="this is an",suffix="that has some")
http://www.ex.org/ex.dt#selector(type=DataPositionSelector,start="4096",end="4104")
etc.

but, if so, it may be relatively easy to mechanically define these things based on the document we would produce anyway. (I am happy taking on the responsibility for that one if we decide to move ahead, I do not want this to fall on the current editors).

WDYT? Is this something we may want to consider?

Ivan

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