- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Tue, 26 Jun 2012 08:47:11 -0600
- To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Cc: James Smith <jgsmith@gmail.com>, public-openannotation@w3.org
Hi Jim, Stian, Bob, I agree with the principle, in which case, we need to consider at least SvgSelector and CssValueStyle. Neither are complete documents as they currently stand, yet it would be nice if they *could* stand alone as separate resources so they can be reused by multiple annotations. For SvgSelector, one fix would be to make it a full SVG document. The reasons we tried to avoid doing that was to not have to re-interpret the viewport and canvas size, and to reduce irrelevant data. Also to avoid having multiple fragments encoded in a single SVG document simply by having more than one path. For CssValueStyle, the reason for not including the element selector is that it's at best meaningless, and at worse wrong -- if it happened to select a real element in the target document, it would mess with the styling. We could make it a fixed, arbitrarily complex string ... but it still might happen. What do you think? Rob On Tue, Jun 26, 2012 at 5:29 AM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote: > Agreed - so go for rdf:value - there is only one way to have > fragments (you can't do a fragment as a set of bytes), the fragment > string does fully represent the FragmentSelector, and it does not have > additional properties like content type. > > Also going into the area of string encoding of fragment selectors > sounds like a mine field.. > > On Wed, Jun 20, 2012 at 5:51 PM, James Smith <jgsmith@gmail.com> wrote: >> On Jun 20, 2012, at 12:36 PM, Robert Sanderson <azaroth42@gmail.com> wrote: >> >>> Dear all, >>> >>> Please could you weigh in on a minor issue of consistency. >>> >>> In the current specification, oa:FragmentSelector uses rdf:value to >>> record the fragment, whereas other resources use the Content in RDF >>> specification to include their data into the graph. >>> >>> Should oa:FragmentSelector also use cnt:chars, or is it more like >>> TextOffsetSelector/TextQuoteSelector in that the properties should be >>> just part of the graph and not able to be exported? Is there a clear >>> rule that we can use to determine which is appropriate? >> >> >> My feeling is that FragmentSelector is like TextOffsetSelector. It's value is a valid fragment, which isn't open to mime type interpretation or character encoding. Fragments have a very specific format (RFC 3986, section 3.5 [pg. 24]) that assumes a UTF-8 superset of US-ASCII (or other suitable superset of US-ASCII) meaningful in the context of the resource to which the fragment is attached. >> >> We might interpret fragments, but that interpretation should be outside the scope of the FragmentSelector schema. >> >> I think the general rule could be that if a resource could stand on its own as a resource (i.e., if we have examples in the wild of similar content being placed at a URL for consumption), then it can use the cnt:chars and related properties. If the value is just a value that depends on some other related context for meaning, then it doesn't need the cnt:chars & co. properties. >> >> -- Jim >> > > > > -- > Stian Soiland-Reyes, myGrid team > School of Computer Science > The University of Manchester
Received on Tuesday, 26 June 2012 14:47:45 UTC