W3C home > Mailing lists > Public > public-openannotation@w3.org > June 2012

Re: Consistency for FragmentSelector value

From: Robert Sanderson <azaroth42@gmail.com>
Date: Tue, 26 Jun 2012 08:47:11 -0600
Message-ID: <CABevsUGhPnAHokC7vJ-R5B1BMmWCsO-tbjkEjYVfjO5UXx3a0A@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 26 June 2012 14:47:46 GMT