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

Re: New Draft comments: Specific Resources

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Fri, 25 Jan 2013 00:18:59 +0100
Message-ID: <5101C163.4080704@few.vu.nl>
To: public-openannotation <public-openannotation@w3.org>
Hi Rob,

> Sorry, but I'm confused!

Trying to remove the confusion as fast as possible...

>>> 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.
>> This was indeed my suggestion. I'm not fond of the oa:SpecificResource class
>> in the first place, see other comments. But at least we'd convey the message
>> that specifiers can function differently from selectors.
> I renamed the module.
> By the last sentence do you mean that it's unclear that there can be
> Specifiers which are not Selectors?

Sorry, wrong typing! I meant Style, which as I took it from Stian and Bob can work a bit like specifiers, but may act differently in other case. I think there's no disagreement between us.

> Also, I don't think I fully grasp your dissatisfaction with the
> Specific Resource class -- is it the name, or its existence?  I take
> it that you do feel that the node in the graph is required, though?

Yes, node is required, it's just that I'm somehow reluctant to having a class which is not fundamentally required. But I agree that it will help, in some cases.

>>> Agreed - this text should be softened to highlight that this is the
>>> preferred way to interpret the specific resource and styles for
>>> traditional rendering, but that agents MAY choose to interpret the
>>> specifiers differently.
> I think this is already in the spec. Unless you disagree with:
> If both exist, then they should be processed in that order, and the
> result is the resource identified by the Specific Resource's URI.
> (We could make it SHOULD, but that section seems more descriptive than
> prescriptive)
> The rationale for the workflow is that segments are almost always
> about representations, not resources.  The same resource could provide
> both image, pdf and plain text representations, which would require
> very different selectors to pick out the intended segment.  Hence, it
> is necessary to consider the State information first in order to
> retrieve the appropriate representation from the resource's URI.

I think no one disagrees with the order of processing, it's just that the spec hints in several places, that all steps should be instantiated. fig 3.1.1 is exemplar, because it shows that the "input" of a Selector is a representation, not a source.

>>> Section 3.4 on styles does also not preclude
>>> styling that is not about the body or target - so it might be worth
>>> breaking the diagram in two by doing the last rendering/styling step
>>> separately from the annotation instead.
>> Yep, that's also what I think.
> I would propose just dropping the diagram at that point -- it wouldn't
> make it any clearer than the surrounding text.

If you feel like it, then it might be indeed the way to go. When I made the comment I thought of proposing an alternative graph, but all that I could think of was not very convincing--too many alternative 'branches' to render.

> However, while section 3.4 doesn't preclude styles that aren't about
> body or target, the only implementation of them does, as a
> SpecificResource is required for oa:styleClass.
> We could drop the abstract class sections from the spec and have them
> only in the ontology, eg sections 3.2 3.3 and 3.4 and promote their
> subsections. Or we could make the descriptions more explicit that
> they're not intended to be used directly.  I would prefer the latter,
> as there may be future Selectors, States and Styles that build off
> them.

That's a good point. And it probably doesn't need more than a single sentence to make.

Received on Thursday, 24 January 2013 23:21:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:03 UTC