Re: "Graffiti" and "Web-Clipper" Annotations

The stylesheet is associated with the annotation, and CSS classes defined
in it are referenced using styleClass from the SpecificResource. The
rationale being that stylesheets are much more likely to be reused across
many annotations, or with multiple targets, even within the same annotation.

For example, to have one target styled green and one target styled red,
there's no need to have two CSS stylesheets, just one with two different
styles, associated with the individual specific resources.

Regarding page width and scale, yes. Reflowable content is a problem when
you want to refer to segments as an area, rather than by reference to the
content.  The dynamic content problem is (IMO) part of the robust anchoring
domain.

Rob


On Wed, Sep 23, 2015 at 10:52 AM, Jacob Jett <jjett2@illinois.edu> wrote:

> One thing that has always felt a bit strange to me is how "hasStyle" is a
> property of the annotation rather than a constraint on or the content of
> the body. Since "hasStyle" is a kind of oa specifier anyway, does it make
> sense to have a discussion about it as a property of the body/target?
>
> Seems like this would be able to apply a specific presentational style to
> the target through the indirection of specific resource. Of course, again
> we'd be adding some more complexity to the model.
>
> @Rob, can you remind us again why the Community Group attached style
> directly to the annotation rather than through specific resource?
>
> Regards,
>
> Jacob
>
>
>
> _____________________________________________________
> Jacob Jett
> Research Assistant
> Center for Informatics Research in Science and Scholarship
> The Graduate School of Library and Information Science
> University of Illinois at Urbana-Champaign
> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> (217) 244-2164
> jjett2@illinois.edu
>
> On Wed, Sep 23, 2015 at 10:27 AM, Benjamin Young <bigbluehat@hypothes.is>
> wrote:
>
>> On Mon, Sep 21, 2015 at 5:18 PM, Robert Sanderson <azaroth42@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 21, 2015 at 3:35 PM, Doug Schepers <schepers@w3.org> wrote:
>>>>
>>>> == Requirements ==
>>>> 1) must be able to indicate the location of a user-archived version of
>>>> a webpage
>>>> 2) should allow arbitrary archiving URLs, formats, and protocols (e.g.
>>>> should not require Memento protocol)
>>>>
>>>
>>> Both of which are covered by TimeState, via cachedSource.  Unless there
>>> is some protocol that doesn't assign a URI to the archived content, and
>>> then it should be outside of the scope of this work anyway as non-web.
>>>
>>> The cachedSource could be a screenshot, and thus should have a format
>>> associated with it.
>>>
>>> 3) must provide a mechanism for representing and reproducing symbols or
>>>> drawings on the rendered area of a document, with considerations for
>>>> relative positioning of the drawings to the content of the page, to x-y
>>>> scroll position, to zoom level, to rendered dimensions, to viewport, and to
>>>> other relative rendering factors
>>>>
>>>
>>> Sounds like SVG as the body of the Annotation?
>>>
>>
>> In my experience with Microsoft Edge, Marqueed.com, and similar products
>> this is the core of what they offer +/- a static (and typically local only)
>> "archive" (think "Save As..." or screenshot output) of a web resource.
>>
>> Most of these systems don't provide any attachment to the
>> original--except perhaps storing the original URL as some metadata in the
>> OneNote file or image's EXIF data...and not much more beyond that.
>>
>> Imagining all of this done online in some way (and not behind "closed
>> doors" in Apple Preview and one's filesystem...), I'd think having a
>> flexible format `body` which can hold SVG, proprietary (if they must...)
>> "ink" formats, or other "scribbling" content should suffice. The other bits
>> such as `target`, `state`, `scope`, etc should be sufficient for mapping
>> the annotation to both the archived copy and even pointing back to the
>> original if the UA want's to take a whack at contextualizing the
>> "scribbles" on the original resource.
>>
>> From what I understand, I believe we can already express SVG bodies via a
>> URL (of course) or as an EmbeddedContent body:
>>
>> {
>>   "@id": "http://example.org/anno1",
>>   "@type":"oa:Annotation",
>>   "body": {
>>     "@type" : "oa:EmbeddedContent",
>>     "value" : "<svg>...</svg>",
>>     "format" : "image/svg+xml"
>>   },
>>   "target": "http://example.org/target1"}
>>
>> However, that obviously doesn't say how or where to display that
>> "graffiti." We have an SVGSelector for that:
>> http://www.w3.org/TR/annotation-model/#area-selectors
>>
>> However, it's not clear to me how that could be used with a flexible page
>> rendering such as HTML in a browser.
>>
>> Microsoft Edge (at least) punts on the problem by fixing the width of the
>> document once you start "scribbling." Likely, CSSStyle could be used for
>> this, but we're currently pretty soft on the requirements on UA's with
>> regard to those:
>> http://www.w3.org/TR/annotation-model/#h4_css-style
>>
>> So...this is an attempt...but it fails... See `target.styleClass`... :(
>>
>> {
>>   "@id": "http://example.org/anno1",
>>   "@type": "oa:Annotation",
>>   "stylesheet": {
>>     "@id": "http://example.org/style1",
>>     "@type": ["oa:CssStyle", "oa:EmbeddedContent"],
>>     "value": "body { height: 1920px; width: 1080px }",
>>     "format": "text/css"
>>   },
>>
>>   "body": {
>>     "@type" : "oa:EmbeddedContent",
>>     "value" : "<svg>...</svg>",
>>     "format" : "image/svg+xml"
>>   },
>>
>> "target": { "@id": "http://example.org/sptarget1", "@type":
>> "oa:SpecificResource", "source": "http://example.org/target1",
>> "styleClass": "...what goes here? not `body`..." } }
>>
>> What it feels like we need is a way to offer (optional?) styles related
>> to the `SpecificResource` that UA's could use to further constrain the
>> presentation of the resource.
>>
>> However, most of what's needed is sizing. In the case of HTML `width` and
>> a "scale" or "text zoom" style thing should suffice. For other media types,
>> though, we'll hit interesting display option problems like "continuous" or
>> "dual page" for PDFs and EPUBs.
>>
>> So. Not sure we've got this one completely solved. ;) It does feel like
>> our `target`, `state`, and `SpecificResource` stuff should be sufficient
>> for pointing to the archived (and/or original) resources.
>>
>> In sum, it seems we need a way to suggest target presentation constraints.
>>
>> Thoughts?
>>
>> Thanks,
>> Benjamin
>> --
>> Developer Advocate
>> http://hypothes.is/
>>
>>
>>> 4) must provide graceful fallback for annotations in UAs that don't
>>>> support drawing or archiving
>>>>
>>>
>>> Not sure what this means in practice.
>>>
>>>
>>>
>>>> == Proposals ==
>>>> === Area selector ===
>>>>
>>>> This should be somewhat similar to area selectors for images, but
>>>> perhaps with added characteristics for viewport, dimensions, scroll, and
>>>> zoom of a document. It should indicate that it's a Web page, and not
>>>> necessarily a traditional image, that it's pointing at.
>>>>
>>>
>>> Not sure this is in scope for the current work, but there's also already
>>> the ability to associate style with a resource, that could specify location
>>> and anything else via CSS.  So I think that at least the basics of the use
>>> case can already be accommodated.
>>>
>>>
>>>
>>>> `archiving` would satisfy requirements 1 and 2. It's most likely to be
>>>> used on a `target`. The corresponding property value would be the URL of
>>>> the archived version of the document/resource. I think the date of the
>>>> archiving action could be derived from the annotation timestamp, so it
>>>> wouldn't necessarily need its own timestamp, though could be an optional
>>>> addition.
>>>>
>>>
>>> The motivation of the annotation is not to archive the page, nor is
>>> archiving a role that the body or target is playing. So -1 to this.
>>>
>>>
>>>
>>>> `drawing` would satisfy requirement 3. I don't know whether it makes
>>>> the most sense as a `target` or a `body`; as a `target` it makes sense
>>>> because it's highlighting specific sections of a document; as a `body` it
>>>> makes sense because it could be additional new content, like handwritten
>>>> notes or symbols. Opinions welcome.
>>>>
>>>
>>> We already have highlighting as a motivation.
>>>
>>> I'm also not sure about this in general ... what would a client do
>>> differently with the information, as opposed to as if there wasn't a
>>> motivation/role?
>>>
>>>
>>> Rob
>>>
>>> --
>>> Rob Sanderson
>>> Information Standards Advocate
>>> Digital Library Systems and Services
>>> Stanford, CA 94305
>>>
>>
>>
>


-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305