Re: Styles

Since our application is annotating data, not documents, we have no
need of Styles. BUT Scope is looking very useful to us, so I want to
make sure that any resolution of the issue of relation between Styles
and Scope doesn't constrain Scope in such a way as to make it less
useful to us. If no change is contemplated to
http://openannotation.org/spec/future/specific.html#Scope you can
possibly stop reading now. :-)

Here is our use case:

In our domain of annotating digital metadata of natural history
specimens, there is a common practice of identifying such a metadata
record by a set of three key-value pairs known as a "Darwin Core
Triple" ("DwC triple"; triple not in an RDF sense, but simply that
there are three of them). At the moment, this triple provides a
Selector against a Target dataset with a URI.  However, almost always
the semantics of the annotation is intended to apply to \any/ dataset
holding data for which the given DwC triples hold. Scope makes it easy
to model an annotator's intent that an annotation is targeted \only/
at a particular dataset and not  meant to apply to all that meet the
Selector value.  At the moment, we expect to depend on domain
community agreement that the default is "all", but we could instead
depend on agreement that this distinction is provided by targeting
some reserved URL like http://purl.org/dwcTriples/anyDataSet.  If
there are any changes to Scope, we at least need to be able to
distinguish these two cases (without giving up tractable reasoning.)

Bob Morris

On Tue, Jan 29, 2013 at 11:38 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 9:13 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:
>
>>>> In addition to the lack of need for changing the doc (see above), I think
>>>> this would have solved the issue: my problem was in fact if two
>>>> annotations
>>>> were targetting one resource with two different styles, and these two
>>>> annotations have each their CssStyle.
>>>> But as I understand now, the "one resource with two different styles"
>>>> should
>>>> actually be two resources (derived from the same segment).
>>>
>>>
>>> Yes, there would be two Specific Resources, each with a styleClass and
>>> the same Source. Example below.
>>>
>>> I think, though, that this does point out a failing in the
>>> introduction of the module where it says that the Specific Resource is
>>> the thing *before* processing the style.  The Specific Resource must
>>> be the result of processing all of the descriptive properties,
>>> including both style and scope.
>>>
>>> I propose changing the description in 3.1 to reflect this.
>>
>> Well, this was in fact what triggered me (and Stian) to argue for separating
>> styles from the other specifiers.
>> http://lists.w3.org/Archives/Public/public-openannotation/2013Jan/0099.html
>> Fig 3.1.1 was a very clear motivator then, in fact.
>
> Yes, "point out a"  should be "reinforces the"! :)
>
>
>> Now if we all agree that specific resources can be the result of styling
>> process too, then it would change quite drastically the validity of the
>> comments we had then.
>
> Indeed. What do others think?  This would be returning more to the
> previous thinking that the Style really is an objective feature of the
> specific resource, and not contextual information from the Annotation.
>
> In other words, the Specific Resource with all of the specifiers would
> identify a particular segment of a particular representation, rendered
> in a certain way, and with reference to particular scoping resources.
> Currently it's only State plus Selector, and the relationship with
> Style and Scope is very unclear.
>
>> Btw I note that the current future spec seems not to take into account the
>> comments we made on optionality of specifiers. Maybe there's other stuff
>> pending...
>
> I wasn't sure if there was consensus on what to do -- leave it, remove
> it, replace it... and then it fell through the cracks, so it's good
> that the discussion came around again :)
>
> Thanks!
>
> Rob
>



-- 
Robert A. Morris

Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390

IT Staff
Filtered Push Project
Harvard University Herbaria
Harvard University

email: morris.bob@gmail.com
web: http://efg.cs.umb.edu/
web: http://wiki.filteredpush.org
http://www.cs.umb.edu/~ram
===
The content of this communication is made entirely on my
own behalf and in no way should be deemed to express
official positions of The University of Massachusetts at Boston or
Harvard University.

Received on Tuesday, 29 January 2013 18:23:26 UTC