- From: Rob Sanderson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Nov 2015 18:44:52 +0000
- To: public-annotation@w3.org
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. 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. 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. 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. -- GitHub Notification of comment by azaroth42 Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/110#issuecomment-159698292 using your GitHub account
Received on Wednesday, 25 November 2015 18:45:00 UTC