W3C home > Mailing lists > Public > public-annotation@w3.org > April 2016

Re: [web-annotation] Dis/Allow both hasState and hasSelector on same SpecificResource?

From: Ivan Herman via GitHub <sysbot+gh@w3.org>
Date: Sat, 23 Apr 2016 05:00:50 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-213665437-1461387647-sysbot+gh@w3.org>

> Assuming #195 <https://github.com/w3c/web-annotation/issues/195>, 
there are two options:
> Require refinedBy as the only way to have both a State and Selector.
> Allow both on the SpecificResource, as well as refining them.
> I prefer 2, for the following reasons:
> You could never reuse a State, as the selectors would always apply. 
This seems a shame, as HttpRequestState is very easy to reuse (here 
are my default headers).
> Inconsistent with Style, Purpose, Scope and Rendering which all 
associate with the SR, and fit into the workflow.
> Inconsistent with existing implementations, whereas refining is a 
new feature [really an improvement/simplification of an old feature 
that was too complex to implement]
> It would not allow for optional States. E.g. TimeState lets you say 
"here is where you can get the exact version I saw" ... but chances 
might be very good that you can just use the source URI if the 
representation doesn't change frequently or significantly
> Choice of State would mean repeating the Selector(s) on each of 
them. This would either make our tree into a graph (and we'd need to 
be clear about where you can shortcut), or be very repetitive.
> I think, along with @nickstenning <https://github.com/nickstenning> 
and @tilgovi <https://github.com/tilgovi> I believe, that the most 
effective way to represent this is to describe as much as possible and
 let the advanced clients figure out what they can do and the less 
advanced just trundle their way through the options until they get 
something that works or that they understand. The more explicit and 
fixed the workflow is, the less room there is for innovation around 
robust anchoring problems that we know we haven't solved.

My fundamental problem is that it is not clear (at least to me) what 
it exactly mean having these to in the same SR. What are the 
processing steps to be taken by an implementation? Actually, the same 
question applies to the situation when there are two selectors side by
 side. The spec does not say whether having several selectors, or a 
selector and a state, etc, mean _disjunctions_ (ie, if one selection 
does not succeed then take the other one) or _conjunctions_ (select 
resources that are characterized by this selection _and_ the other).

1. If it is a disjunction then of course it makes sense to have 
several things side-by-side, but I am not sure I see a good use case 
for that
2. If it is a conjunction, then it is probably true that the same 
effect can be described by refinements (at least in the cases I 
listed, I did not look at style, purpose, etc.)

I do understand some of your arguments, eg, related to reuse, and they
 are indeed compelling. But the semantics of your example on timestate
 becomes a bit fuzzyer for me in terms of the exact semantics of 
multiple entries.

Whatever our decision on the issue is, I think the fundamental point 
is that the exact semantics MUST be spelled out.

GitHub Notification of comment by iherman
Please view or discuss this issue at 
 using your GitHub account
Received on Saturday, 23 April 2016 05:00:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:45 UTC