W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: Annotation Concept vs Document (was Level 1 comments)

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 29 Jan 2013 17:13:32 +0100
Message-ID: <5107F52C.60700@few.vu.nl>
To: <public-openannotation@w3.org>
On 1/29/13 4:59 PM, Robert Sanderson wrote:
> On Tue, Jan 29, 2013 at 8:45 AM, Antoine Isaac<aisaac@few.vu.nl>  wrote:
>>>>> * The Proxy construction for talking about the
>>>>> resource-in-the-context-of-the-Annotation was not especially liked.
>>>>> This would be the equivalent of a Specific Resource that we have now.
>>>> I would disagree. In all examples I can think ok, the resources
>>>> considered
>>>> by the annotation are described in "objective" terms, not "specific to
>>>> the
>>>> annotation at hand". A text body and an image target do not change across
>>>> context.
>>> It was seen somewhat as the equivalent of reifying annotea's context
>>> predicate.
>>> So it could be read as:  In the context of the annotation, I'm
>>> referring to this segment of the resource.
>> Yes but a segment/state resource is not an annotation-specific perspective
>> of one the source. It's objectively defined, and can be re-used across
>> annotations. In fact I'm eager to re-visit a too quick interpretation
>> yesterday (below). A Styled resource is also objective in a way: two
>> annotations targeting two resources with different styles are indeed
>> targeting two plainly different resources.
> Yes, I agree. And I'm happy that there is at least the styleClass
> property on the Specific Resource that makes this apparent.
> I also agree that the specific resources are objectively defined,
> which in my view is a significant improvement over Annotea and similar
> models.


>>>> Hmm, in fact there is a problem: the styles. These can be
>>>> annotation-specific.
>>> We could add text to the paragraph starting "When rendering a Specific
>>> Resource,...":
>>> If a Specific Resource has a styleClass, but no such class is
>>> described by a CssStyle attached to the Annotation, then the
>>> styleClass MUST be silently ignored.
> Which I've done, as it seems like a reasonable processing
> requirement... and there's no other realistic option anyway.
>> 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.
Fig 3.1.1 was a very clear motivator then, in fact.

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.

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...

Received on Tuesday, 29 January 2013 16:14:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:21 UTC