Re: Style Issue

Looking further, there's the (very old) gss:style predicate:
    http://www.w3.org/2001/11/IsaViz/gss/gssmanual.html#styles

We could use that, which is at least a W3C page if not a recommendation.

Rob






On Wed, Jan 2, 2013 at 11:02 AM, Robert Sanderson <azaroth42@gmail.com>wrote:

>
> Hi Tim,
>
> Many thanks for the feedback!
>
>
> On Wed, Jan 2, 2013 at 10:46 AM, Tim Cole <t-cole3@illinois.edu> wrote:
>
>> I agree with your analysis that the previous solution for style has flaws
>> that need to be addressed.****
>>
>> [...] but I worry a little about the minting of the new property
>> oa:styleClass and thinking about how it will be used.
>>
>
> Agreed. I looked for existing RDF predicates, but didn't find any that
> were appropriate.
>
> **1.       **What are the implications for an annotation serialized in
>> XHTML+RDFa (i.e., where the XHTML class attribute is intrinsically
>> available for styling)? Do we have to mint our own styleClass property? Or
>> could we more simply leverage the existing
>> http://www.w3.org/1999/xhtml:class as the property?
>>
>
> Is that valid RDF? If it is, then I'm (personally) in favor of using it
> instead of inventing our own identical predicate.  While I agree that it's
> possible to use in other XML based contexts, I'd like to be certain it's
> possible to import something defined as an XML attribute into RDF as a
> predicate.
>
>  2.       **The value of a styleClass property of a target or body
>> resource is presumably in almost all cases specific to an individual
>> annotation or finite set of annotations, right?
>>
>
> Yes.  Otherwise we could attach it to the resource directly, but then it
> would be of global scope.  This would become problematic when there was an
> annotation with a style that defined blocks for (say) "Body" and "Target",
> and then two different annotations associate this blocks with the same
> resource.  It could happen when a client has default styling rules it
> applies, and the same client is used to create the two annotations.
>
>
>> So the domain of oa:styleClass will always be (practically speaking)
>> oa:SpecificResource? So you'd almost always use the oa:SepcificResource
>> construction even in the absence of Selector, Scope and State?
>>
>
> Yes. And agreed that this is a shame, compared to the @document url() rule
> construction, but ...
>
>
>>  Probably moot because I can't come up with a practical use case where
>> you'd want to apply style on a target or body that was not an
>> oa:SpecificResource.
>>
> ... it does seem like the appropriate compromise given this point.
>
> Thanks again, and we would welcome any other feedback on this issue!
>
>
> As a logistical point, we intend to make the new draft available to the
> list for further feedback before the end of the week.  We would love to
> then get feedback in order to publish it before the beginning of February,
> and hopefully closer to the middle of January.
>
> Many thanks,
>
> Rob
>
>
> *From:* Robert Sanderson [mailto:azaroth42@gmail.com]
>> *Sent:* Thursday, December 20, 2012 10:15 AM
>> *To:* public-openannotation
>> *Subject:* Style Issue****
>>
>> ** **
>>
>> ** **
>>
>> 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****
>>
>>   ****
>>
>
>