Re: Style Issue

On Thu, Jan 3, 2013 at 7:20 AM, James Smith <jgsmith@gmail.com> wrote:

>
> For example, we might have the following simplified annotations:
>
> _:structuredAnnotation1 a oa:Annotation, oax:Highlight,
> sga:AdditionAnnotation ;
>   oa:hasTarget _:textTarget1 .
>
> _:textTarget1 a oa:SpecificResource ;
>   oa:hasSource <teiFile> ;
>   oa:hasStyle _:cssStyle ;
>   oa:hasSelector _:selector2 .
>
> _:cssStyle a oa:Style, cnt:ContentAsText ;
>   cnt:chars "vertical-align: super;"
>   dc:format "text/css" .
>
> _:selector2 a oax:TextOffsetSelector ;
>   oax:begin "..." ;
>   oax:end "..." .
>
>

This would become in the new draft:

_:structuredAnnotation1 a oa:Annotation ;
  oa:hasMotivation oa:Highlighting ;
  oa:hasTarget _:textTarget1 ;
  oa:styledBy _:cssStyle1 .

_:cssStyle1 a oa:CssStyle, cnt:ContentAsText ;
  cnt:chars ".super {vertical-align: super}" ;
  dc:format "text/css" .

_:textTarget1 a oa:SpecificResource ;
  oa:hasSource <teiFile> ;
  oa:styleClass "super" ;
  oa:hasSelector _:selector2 .
[...]

Though could you clarify why the style is associated via a second
annotation, rather than in the first?  It's probably obvious and I'm just
missing it :)

It's easy to process all of this into a set of spans that combine all of
> the style information from any overlapping annotations. I've put a
> screenshot of our current (alpha) viewer at
> http://mith.umd.edu/tmp/sga-shared-canvas-3Jan2013.png to illustrate what
> overlapping highlights end up looking like.
>

This looks great :)



> I suspect our use of style reflects a much earlier draft of the OAC
> specification. What would our RDF look like with the options under
> consideration? What additional code would we have to write to make use of
> the style information?
>

As above.  The code needed, I guess, would be to extract the appropriate
block from the CSS, or to have the style as a real resource that gets
imported into the display and then just attach the styleClass to the
generated HTML.



> If we assume that we only attach class names to the annotation, then we
> can reduce the _:textTarget1 resource to the following triples (and making
> up the "oa:styledByClass" and "oa:styledByCSSDocument" predicates):
>
> _:textTarget1 a oa:SpecificResource ;
>   oa:hasSource <teiFile> ;
>   oa:styledByClass "foo" ;
>   oa:styledByCSSDocument <referenceToCSSDocument> ;
>   oa:hasSelector _:selector2 .
>
>

Almost. styledByClass = oa:styleClass, and styledByCSSDocument =
oa:styledBy on the Annotation.

If we simply dump the CSS rules and classes into the HTML as-is, then we
> risk collisions with application stylesheets. The annotations are
> independent of the implementation of the client application used to
> visualize them, so we can't assume that they can share the same stylesheets
> any more than we can assume that two different annotations will share the
> same stylesheets.
>

Yes. To do it properly to avoid conflicts isn't trivial.  To do it quick
and dirty is, as above, just dumping it directly into the HTML and letting
the browser sort it out.  In comparison, the current draft version (with
only the value block) is easier the content isn't valid CSS. The originally
proposed version is much harder, as you really have to parse out the CSS to
extract the @document url() rules.



> The OA draft already assumes that we'll have an RDF/XML parser available
> (which we don't - we're using RDF/JSON so we don't have to load an
> additional JavaScript library). Do we also need to assume a CSS parser?
>

The current draft moves serialization out to an Appendix, and provides a
recommendation for JSON-LD.  We think that this will aid adoption, as a
JSON format has been asked for many many times.

As far as the CSS parser goes, the ".class { block }" constructions could
likely be parsed out with a regular expression (I know, two problems...)
which would catch 99% of the uses of Style.  The cases it wouldn't catch is
if the annotation refers to a CSS document that is *also* used as a regular
HTML stylesheet and contains non class based rules.

A full CSS parser in Javascript is available:
http://www.glazman.org/JSCSSP/
But I have yet to try it out.

HTH!

Rob


>
> -- Jim
>
> On Dec 20, 2012, at 11:15 AM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>
> Dear all,
>
> While writing up the new method of attaching Styles to Annotations, we ran
> into the following unanticipated issues.  We feel this makes the current
> solution for style unworkable, and propose a slight modification that
> should make things easier all round.
>
> Issues:
>
> 1.  Styles reference the resources in the graph by URI, using the CSS
> @document rule.  While this makes matching easy, it becomes impossible with
> the republishing method that is recommended in the specification.
>
> For example, a system publishes an Annotation A with an embedded body
> URN:B.  URN:B is thus the URI that is in the Style.
>
> A second system harvests the Annotation, republishes it at A2, and the
> body as a web resource at HTTP URI B2.  It should also assert that B2
> equivalentTo URN:B.  So now the style refers to the equivalent resource,
> not the body itself and systems will always have to check both.
> This isn't the end, however, as this is likely to happen multiple times in
> a distributed system.
> The Style could be updated, but it might be a web resource that is
> maintained outside of the annotation system and these changes would not be
> reflected in the copies.  It also relies on consuming systems to understand
> the content of Styles, which seems above and beyond what they should be
> expected to do.
>
>
> 2.  As Styles refer to the URI of the resource, they cannot be re-used
> across multiple annotations.  This means that there necessarily must be one
> style per annotation, which is contrary to most uses of CSS and really to
> the web architecture in general.  So every system that has a style for its
> annotations must create a new style resource for each annotation, rather
> than just a default few.
>
>
> 3.  Following from 2, there is no reason to *not* embed the style if it is
> tied 1:1 to the Annotation. This defeats the purpose of some of the changes
> from the first draft, eg to make it a valid CSS resource rather than just
> the value block.  It also brings up a (lesser) documentation/learning issue
> that to understand Styles you need to understand the Content in RDF model,
> which otherwise is not necessary.
>
> We consider the sum of these issues to be a show-stopper.
> Our proposal for how to adapt it is:
>
> 1.  Keep the Style resource a valid CSS document attached to the
> Annotation, still using oa:styledBy, as in the current proposal.
>
> 2.  Instead of using the complex @document url() rule construction,
> instead use the more familiar class name construction.
>
> 3.  Have a property in the Annotation graph on the resources to be styled
> that records the class name.   Systems then match the property to the
> respective name in the CSS document.
>
> This solves Issue 1 because the property can be reattached easily to the
> new resource, just like all of the other properties and relationships.  At
> the same time, we use only basic CSS constructions rather than the CSS
> Level 3 @document construction.
>
> It solves Issue 2 because the class names can be re-used across multiple
> annotations.  I also makes it easier to swap styles across a range of
> annotations -- simply change the referenced CSS resource and they all
> change, rather than the current method (edit all of the embedded CSS blobs)
> or the first version (change the references on all of the Specific
> Resources).
>
> It solves Issue 3 by solving Issue 2, as the style is not tied 1:1 with
> the Annotation.
>
> Thus:
> _:Anno a oa:Annotation ;
>   oa:styledBy <Style1> ;
>   oa:hasTarget <SpTarget1> ;
>   oa:hasBody <Body1> .
>
> <SpTarget1> a oa:SpecificResource ;
>   oa:hasSelector <Selector1> ;
>   oa:styleClass "red" ;
>   oa:hasSource <Target1> .
> ...
>
> Where Style1 has the representation:
> .red { color : red }
>
> This seems to capture the best parts of the current proposal while solving
> the issues that have come up with it.
>
> Please let us know any thoughts or comments on this revised approach.
>
> Many thanks,
>
> Rob, Paolo and Herbert
>
>
>
>