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

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
>>
>
>