Re: Style Issue

On Jan 3, 2013, at 11:09 AM, Robert Sanderson <azaroth42@gmail.com> wrote:

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

The first content annotation we have maps a block of text from the TEI onto the canvas (the body is the span of TEI and the target is the canvas). The second annotation is a highlight annotation that marks part of that first annotation as a particular type (an Addition, in this case) that should be rendered superscript (it has no body, but targets a span of the TEI).  Some additions are rendered subscript. Hopefully I didn't mess up my _:... node names and confuse things -- I was copying from our internal documentation and combining a couple examples. As ASCII art, with addition/deletion highlights treated as a kind of stand-off markup of the TEI:


Additions mapped to TEI -->        v---------------------------v
Deletions mapped to TEI -->  v-------v     v---------------------v
   TEI mapped to canvas --> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
                 Canvas -->[-------------------------------------------]

The range of characters for the two annotations in my example are different. I hid that behind the "..." in both cases. Only the addition/deletion highlight annotations have styles associated with them.

Would you recommend that we move our "sga:AdditionAnnotation", etc., to the motivation? Something like:

_:structuredAnnotation1 a oa:Annotation ;
  oa:hasMotivation oa:Highlighting, sga:AdditionAnnotation ;
  ... .


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

Thanks!

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

I'm uncomfortable doing too much quick-n-dirty mixing of OA styles and browser page styles, so I'll do some lightweight parsing. For what we need right now, it won't be a big performance killer or complication.

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

Thanks for the rewrite using the newer predicates/model. It helps me see where we'll need to modify our code. I knew the OA draft was just that (a draft), so I'm not surprised or upset about having to do this.

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

Cool. I'll take a look at it. Meanwhile, we'll probably go with a simple regex-based parser to pull out what we need. Given that we're both producer and consumer of the annotations in question, we can control things a lot more right now. I'll worry about moving to full CSS support when we're ready to ship a generic shared canvas viewer. And +1 on the JSON-LD serialization.

-- Jim