Re: Style

I believe this new approach is cleaner and more practical for reusing
Specific Resources without merging the presentation layer with the actual
resource. A big +1

IhasState has a tighter relationships with the resource. In fact the
hasState should be necessary to retrieve the correct representation of the
resource  so that the annotation can be placed correctly - while the style
was purely related to the presentation of the annotation. I am sure there
are cases where you can ignore hasState and still place the annotation but
I would not feel safe in saying that would be the norm. Therefore hasState
seems more belonging to  the Specific Resource.

Paolo

On Tue, Jul 31, 2012 at 12:36 AM, Randall Leeds <randall.leeds@gmail.com>wrote:

> On Mon, Jul 30, 2012 at 9:19 AM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
> >
> > [Moderator bouncing message, stripped of attachment which was to big for
> > mailing list size limit.
> >  The attachment is archived at:
> > <
> http://lists.w3.org/Archives/Public/www-archive/2012Jul/att-0038/proposal_style.png
> >]
> >
> > Dear all,
> >
> > There was an offline discussion last week concerning the current use
> > of oa:hasStyle being attached to the Specific Resources which we
> > should continue online in the larger group.
> >
> > The concerns that were raised with the current model for style:
> >
> > * Specific Resource nodes cannot be re-used between annotations, as
> > someone might attach a Style to it in another annotation, thereby
> > changing all of the uses of the Specific Resource.  If the nodes
> > cannot be reused, then they're significantly less valuable
> > (essentially they may as well be blank nodes!)
>
> Which makes the inline target language terribly inaccurate! ;)
> http://www.openannotation.org/spec/core/#TargetInline
>
> I agree. We could do better.
>
> In particular, I've been re-thinking the importance of fragment
> identifiers as targets where they are well understood. If URIs with
> non-empty fragment identifiers could be used as targets, then some
> simple uses become very attractively minimal. One might assert the
> hasSource to facilitate query-ability, but the annotation could be
> quite few triples.
>
> > * The Specific Resources would then identify the section of the
> > representation, rather than a styled section of the representation.
> >
> > * Conceptually the style is for the Annotation.  It would be cleaner
> > if it were attached to the Annotation rather than the individual
> > Specific Resources.
> > * It would thus be somewhat easier to ignore for clients that don't
> > expect to process it.
>
> +1
>
> >
> > * The CssValueStyle class is a nasty hack -- it's not a valid CSS
> > file.  If we're just creating our own hack, we can do it in a
> > different way just as easily.
> >
> >
> > And after some discussion the proposed change was:
> >
> > Instead of attaching to the Specific Resource, oa:hasStyle would
> > attach to the Annotation.  The object of the relationship would be a
> > valid CSS file that describes all of the stylistic features for the
> > resources that are part of the annotation graph.
> > A diagram form is attached.
>
> I wonder if it makes sense to do the same with hasState, only it's
> less clear to me what a real, implemented example would look like than
> it is with the example hasStyle CSS.
>
>


-- 
Dr. Paolo Ciccarese
http://www.paolociccarese.info/
Biomedical Informatics Research & Development
Instructor of Neurology at Harvard Medical School
Assistant in Neuroscience at Mass General Hospital
+1-857-366-1524 (mobile)   +1-617-768-8744 (office)

CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
may contain information that is considered
to be sensitive or confidential and may not be forwarded or disclosed to
any other party without the permission of the sender.
If you have received this message in error, please notify the sender
immediately.