Re: Last draft comment: Specifiers and Specific Resources

Hi,

OK for the changes!

But though the bit added to multiplicity is alright, it is not precisely what I meant. I guess it's just impossible for me to express it right :-(

Let's try again. The case I have in mind is

<ann> a oa:Annotation ;
  oa:hasBody <body1> ;
  oa:hasBody <body2> .

<body1> oa:styleClass "important" .

<body2> oa:styleClass "emphasis" .

No multiplicity involved here. But "important" and "emphasis" are defined in *two different styles*. Say, <style1> and <style2>.

Attaching both styles at the level of the annotation is possible:
<ann> a oa:Annotation ;
  oa:styledBy <style1> ;
  oa:styledBy <style2> .

But then I'm unclear how a data consumer would know which is the style that corresponds to each class. They could inspect the styles and see whether there's a corresponding class in it. But this could have issues (e.g. two styles defining a same class but with different stylings).

And of course Stian's suggestion that <anno> could have some other property, with a value that would be styled according to a third style, would make the picture even more confusing.

Or is it just the case that such mind-boggling situations are *not allowed* in OA?

Antoine


> On Sun, Feb 3, 2013 at 10:51 AM, Antoine Isaac<aisaac@few.vu.nl>  wrote:
>
>> 1. "The Style resource is linked from the Annotation, however its only
>> implementation (oa:CssStyle) requires the Specific Resource to have
>> additional information."
>>
>> I'd move this one to section 3.4. It's quite specific for an introduction,
>> and makes the introduction depending on later changes on details.
>
> Sure. Done.
>
>> We had the discussion in [1] and I'm still uneasy with the fact that the
>> spec does not explicit sort out in 3.4 how an annotation would handle
>> different styles that are each used by one specific resource of a same
>> annotation.
>
> True. Either styledBy should have 0..* cardinality, or the
> multiplicity constructs should say that they can be the object of
> styledBy.
> However it brings up ordering questions as to which conflicting style
> definition in multiple Style resources would take precedence... this
> would be solved with either a Choice or a List construction, so I've
> added styledBy to the multiplicity document.
>
>
>> And the end of Stian's email [2] hints that there could be
>> styles that apply to no specific resources. While I'm not calling for the
>> spec to solve these issues now - as Stian puts it, it's even not sure they
>> would happen. I'd just advise against putting dependencies on this in the
>> text outside of section 3.4. And perhaps an editor's note in that section
>> would be good to address readers' doubts, if just to say that the current
>> situation may not answer all implementation issues on the matter.
>
> It might happen when the annotation creation client always associates
> a default style with the Annotation, but none of the bodies/targets
> have a styleClass property.  Doesn't seem like a big deal?
>
>
>> 2. "The scope, such as a webpage containing the target image, is linked with
>> oa:hasScope and does not convey a validity test for the annotation, just
>> that the web page was being viewed when the Annotation was created."
>
>> We should not mention a "validity test" notion here. Unless I've missed
>> anything, this is the first (and only?) time it appears in the entire
>> documentation. Plus, if you keep it, then I'll have to ask either what such
>> test mean, or why scopes would not convey it. And I'm not sure any of us
>> wants this ;-)
>
> :) I just deleted these two sentences and merged the more general
> descriptions with the previous paragraph.
>
>
>
>> 3. " For example, it is possible to use URIs with fragments directly, as in
>> the Core document, the FragmentSelector class, for rectangular areas either
>> media fragments or the SvgSelector and for plain text documents either RFC
>> 5147 or the Text Selectors. "
>>
>> This sentence could do with extra punctuation - or some splitting, as you
>> see fit.
>
> Agreed. Fixed.
>
> Rob

Received on Monday, 4 February 2013 10:28:02 UTC