Make Selectors available for the wide world?

[iherman]

Selectors (and its subclasses) are very powerful. 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.

Can we make steps for reuse of these specifications without disturbing too much our work? Here are the alternatives I see.

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 document, obviously, as well as the JSON-LD @context file. It would be invisible for the pure JSON-LD usage and document.
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 separate JSON document, the RDF document can stay as it is if we also adopt (1) above (RDF people are used to using part different vocabularies or part of an existing 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.

What I meant for (3) is to define something like:

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. It may be relatively easy to mechanically define these things based on the document we would produce anyway. However, it does raise issues related to the standard definition of fragment ID-s. However, even if we do not do it in this Working Group, by doing (1) and (2) we would facilitate other groups (Community or Working Groups) to pick this up.

[tilgovi]

I should say "interactions" instead of "UX". I find it hard to generalize the workflow of annotation. However, translating between selections and selectors is clearer.

[iherman]

@azaroth,

I would be okay to separate a more generic SpecificResource class from the Annotation specific functionality. I agree that Selector and State are generic, and the rest are Annotation specific.

Great. We have an agreement:-) I'm (still) not keen on a second namespace, as in the most common use (annotations), people will use the wrong one. Also, they would be potentially even correct to use the wrong one ... they're just using the CG versions of those predicates.

These are indeed good points. I yield:-) As folks familiar with RDF are okay to pull out individual terms from ontologies, having them separate doesn't seem beneficial to me. If someone can outline the advantages of a separate namespace would be appreciated.

The core seems like:

oa:ResourceSegment (or something like that) oa:Selector (and subclasses) oa:State (and subclasses) oa:hasSelector, oa:hasState, oa:hasSubSelector, oa:hasSubState +1

ResourceSegment, for my understanding, suggests some sort of an interval, not a specific 'point' in the resource (which is part of what selectors do). ResourceSelection?

And then the annotation specific part:

oa:SpecificResource subClass of oa:ResourceSegment oa:hasScope, oa:hasPurpose, oa:renderedVia, oa:styleClass/oa:styledBy To me the Note is "If you want to describe regions of representations, then you need to have a Selector to describe the region, a ResourceSegment to identify it, and you might need a State to get the right representation from the Resource... here are those components." The URI of the RDF namespace is irrelevant.

O.k. Let us go for this approach in the vocabulary and model document. The exact formulation of the note is for later anyway (but it is along the lines of what you propose).

I guess this issue may now become a 'purely' editor's job:-)

[jjett]

+1 from me for @azaroth42 's proposed fix.

Still not certain about how the semantics for oa:hasSubSelector and oa:hasSubState work. They both nest below the object of oa:hasSelector (or oa:hasState, as the case may be) and the object of oa:hasSubSelector (i.e., subselectors can an infinitely deep nest of recursions but not the case for selectors, the semantics don't seem consistent).

[iherman]

Discussed on 2016-03-04 telco. Accepted the comment above: https://github.com/w3c/web-annotation/issues/110#issuecomment-188963956 as a way forward

See: http://www.w3.org/2016/03/04-annotation-irc#T16-32-21

[azaroth42]

Specification work done: http://w3c.github.io/web-annotation/vocab/wd/#resourceselection I propose that we create a new (postponed till after we enter CR) issue for the Note?

[iherman]

Specification work done: http://w3c.github.io/web-annotation/vocab/wd/#resourceselection I propose that we create a new (postponed till after we enter CR) issue for the Note?

Good idea.

Ivan

[iherman]

Per decision of the telco, and also per https://github.com/w3c/web-annotation/issues/110#issuecomment-193889352, a separate issue and label has been created for the relevant note (#192). This issue is thereby closed.