RE: Style Issue

1.       Probably no with regard to gss:style. Was tied to some of the
contemporary CSS work, which has moved on, while GSS seems entirely dormant.
And as you say, it never reached the level of W3C Recommendation. But it
does give some reinforcement to the approach you've proposed.

 

2.       With regard to whether the XHTML attribute class could be
considered as an RDF predicate (i.e., xhtml:class), a few years back in the
development of RDFa this was considered:  

 

  http://www.w3.org/2006/07/SWD/track/issues/3 

 

My reading is that in the end it was decided that in general XHTML @class
was too semantically ambiguous except when it's value was
namespace-qualified, in which case it mapped better to rdf:type (i.e., as
opposed to xhtml:class), and of course rdf:type is not what we want at all.


 

Interestingly as part of the same discussion they did consider the
possibility of@role as a potential predicate (in RDF sense). Had XHTML 2.0
ever gone anywhere they were talking about @role becoming xhtml2:role in
RDFa, but then XHTML 2.0 died. So the idea of some XHTML attributes being
treated as RDF predicates not entirely unreasonable. Just not @class given
wide range of ways it is used in XHTML.

 

So probably too much baggage to try and use xhtml:class. Too bad. Unless you
read this discussion differently.

 

So I guess oa:styleClass it is, unless someone has another take on how to
avoid.

 

3.       But there will not, I assume, be an oa:styleID predicate? We would
limit ourselves to CSS class selectors?

 

Thanks,

 

 

Tim Cole

University of Illinois at UC

 

 

 

From: Robert Sanderson [mailto:azaroth42@gmail.com] 
Sent: Wednesday, January 02, 2013 12:14 PM
To: t-cole3
Cc: public-openannotation
Subject: 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