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

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
>