Re: [web-annotation] Make Selectors available for the wide world?

@azaroth42:
> Regarding overhead, my opinion is that if they go through the 
process separately, we're making extra and unnecessary headaches. We 
would need to do the selectors document first, in order to refer to it
 from the model document.
> 
I do not think that is a problem. We are already restructuring 
documents, cutting one document into two. That is why I raise this 
*now*; doing it at this phase is no big deal. Doing it much later may 
generate headaches.
> And then we'd need (I assume) a vocab document for the selectors, 
separate from the selector model document ... and for the annotation 
vocab document to include the selectors in the external section.
> 
> If we're going to split things out, then I think that the embedded 
content / textual body is an even better candidate. We know that there
 are multiple uses, because we have it, as does ActivityStreams, as 
did the Content in RDF not-quite-spec. No one else (that I know of) 
has approached the selector issue?
> And if they did, I don't see why they would be somehow afraid to use
 it if it was in an Annotation spec? The great thing about RDF is that
 you can pull appropriate classes and predicates from different 
vocabularies and use them as needed.
> 
>From an RDF point of view: yes, you are right. RDF people can pull 
classes and predicates and they do it as their hearts' content. There 
may be a healthy reluctance, though, to do that if it is part of a 
larger and more complicated vocabulary, hence my proposal to put it 
into a separate namespace. Really, doing that on the RDF side is just 
syntactic sugar at this point.

But let me repeat what I said earlier: *no, I do not think the 
vocabulary document has to be split*. The *only* change I propose for 
that document is to introduce a separate namespace for the selector 
classes and the selector specific properties. That is it. 

It is the JSON users that I am really concerned about. There is no 
tradition of partial reuse in that community. People "simply" wanting 
to use an alternative mechanism to fragment identifiers to describe a 
portion of a document will not reuse a portion of a major JSON 
vocabulary; they will reinvent the wheel. Unnecessarily. 

Let us not forget that we are addressing two communities which are 
fairly distinct. I am not worried about the RDF one...

> Regarding the SpecificResource, yes you successfully did not put 
type: SpecificResource into the RDF ... but the first blank node 
serves the same purpose, just using different non-standard vocabulary.
 To be clearer, my assertion is that you need some resource to play 
the role of the SpecificResource to make a Selector useful.
> 
Yes, the first blank node would serve the same purpose. So what? Yes, 
of course you need some resource to "encapsulate" a Selector. Again, 
so what?
> I don't understand the reluctance to treat section 4 as a whole. 
State, Style, Scope and renderedVia are hardly annotation specific and
 would just be reinvented unnecessarily.
> 

A SpecificResourse is just an RDF Resource. The only thing that it 
brings to the table is that *it is the domain for a number of other 
properties* that we define for annotations. Like roles (or whatever 
the name will be:-), or states; both are annotation specific things, 
just look at the various values we define for those properties.  None 
of those properties/values have any sense in my foaf example and I 
would not reinvent them for my application because I do not need them.
 To take another example, I may use a similar construction for adding 
a complex metadata (say, an RDF version of ONIX metadata) to portion 
of a publication: the current annotation specific properties have no 
meaning in that context.

What *is* true is that, in an ideal world, the very concept of 
Specific Resource could be split, too. I could imagine having a 
separate class and have something like (just inventing the term on the
 fly):

```
<http://bla.bla.bla <http://bla.bla.bla/>> a selector:SelectedResource
 ;
        selector:source <http://a.b.c/ <http://a.b.c/>>,
        selector:select [ a  selector:TextPositionSelector;
                selector:start 412;
                selector:end 795
         ]
.
```

and then declare ``oa:SpecificResource`` to be a subclass of  
``selector:SelectedResource`` as far as the RDF vocabulary goes. 
*That* would be even cleaner. The reason I did not propose that, 
originally, is to avoid any extra complication. However, it is 
perfectly doable to do that as well: it means a little bit more in the
 RDF document on the model, and hardly any difference in the JSON 
version, because it would be hidden in the ``@context``.

But I am happy to make the minimal step only, and stick with what I 
originally proposed.




-- 
GitHub Notification of comment by iherman
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/110#issuecomment-159906649
 using your GitHub account

Received on Thursday, 26 November 2015 12:59:35 UTC