Re: New Draft comments: Specific Resources

On Tue, Jan 22, 2013 at 7:34 AM, Stian Soiland-Reyes
<soiland-reyes@cs.manchester.ac.uk> wrote:
> On Sun, Jan 20, 2013 at 9:11 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:
>
>> 1. Positioning of Rendering
>> Does Rendering really fit a section on Specific Resources? States and
>> Selectors are about restricting the "extent" of a resource being annotated.
>> But Styles seem quite different beasts. This is in fact quite explicit in
>> Fig 3.1.1 that positions "Specific Resource before styling. Bar comment 11,
>> there's also the quite puzzling fact that oa:styledBy is attached to an
>> Annotation resource, not to a specific body or target.
>> So I'd suggest to move Styles in their own module. *Or* to label the module
>> as "Specifiers". Indeed, for a reason that I'm entirely grasping,
>> "specifiers" include more than what is needed to produce Specific Resources;
>> that could have a nice effect of fitting better the entire module as it is
>> defined now.
>
> We discussed this in Boston I think - the thing is that styling could
> have more or less semantic meaning depending on the annotation - for
> instance an annotation tool could let the user draw on a resource, and
> then in an annotation body the user might say "The circled part is
> important for the area coloured blue" (where the two areas are two
> specific resources using svg shape selectors, with colouring added by
> style) . Hence to understand the annotation it is best to apply the
> styles.
>
> However I agree in that styles do not make the resource "more
> specific" - it is more of a kind of modularity. So your suggestion is
> to simply rename the chapter to "Specifiers" and keep the classname
> oa:SpecificResource? (as styles are attached to annotation) I can +1
> that.
>
>

I (think that) I like Stian's "modularity" view as it applies to one
of our central uses of annotation of data with  data quality control
assertions.  In some of those cases, the Target is a database and the
SpecificResource is the data returned by a query. The annotations
assert Internal inconsistencies or missing data within that set (the
"circled" data records) and those returned by another query (the
"blue" data records).

In one use of the above we do something about which I do not see many
analogies for documents.  That is, we sometimes regard the above
situation as being assertions about \all/ data with a schema for which
the queries make sense. At the moment, only one thing comes to mind
vaguely related to that for documents. This would  would be assertions
about the failure of recommended semantics of document structure.  For
example, in English composition at school we are taught that the first
sentence of a paragraph should always introduce the topic of the
paragraph, and each paragraph should have a single topic.  Every
annotation asserting a failure of that principle can probably be
asserted in OA in a single "modularization" sensu Stian.

Bob Morris

-- 
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, 22 January 2013 14:30:44 UTC