Re: [web-annotation] Multiple Selectors

@iherman, @azaroth42 Sorry to dodge @azaroth42 's request to repeat 
all three patterns but only the first pattern is actually pertinent. 
This is because the way that the UC3 example is written is that the 
choice happens at the top level. So either you have the simple case of
 the text quote selector or you have to follow the selector chain. 
Since UC1 is what we're actually debating the following examples are 
for UC1. 

Generally speaking I think that nesting / chianing multiple selectors 
beyond two levels of depth is going to be highly unlikely (probably 
will occur > 1% of the time). So these four deep examples are extreme 
edge cases (they are honestly outliers).

Thinking about a situation that might call for such heroic efforts to 
dig, I looked at the HathiTrust Digital Library's infrastructure and 
supposed that if I wanted to annotate a particular piece of text on a 
particular page in a particular volume then I might have to do the 
following -- I would specify a particular volume using a query to the 
HTDL's DB (this isn't actually true -- we have persistent URIs for 
everything at this level). Next I would specify what page of the 
volume I wanted (necessary because each page is a distinct text--image
 is also available--file; we know that our scholars want more granular
 things than this and since we have the files in hand minting 
identifiers for them seems to be a good next step to facilitate the 
specification of even more granular things -- so this part is going 
away too). Afterwards I specify a portion of the page and finally 
apply the text position selector exactly as in the existing examples.

Rob's Proposed Solution:

{
  "type": "SpecificResource",
  "source": "http://example.org"
  "selector": 
    {
    "type": "foo:QuerySelector",
    "value": "knownItem",
    "subSelector": {
      "type": "foo:PageSelector",
      "value": "desiredPage",
      "subSelector": {
        "type": "FragmentSelector",
        "value": "namedSection",
        "subSelector": {
          "type": "TextPositionSelector",
          "start": 5 // relative to target#namedSelection
          "end": 28
          }
        }
      }
    }
}

Hugo's Alternative (which I should note was proposed in academic 
circles by Dubin, Jett & Senseney at the 2013 Balisage Conference) 
appears as follows.

{
   "@type": "SpecificResource",
   "selector": {
       "@type": "TextPositionSelector",
       "start": 5, // relative to index.html#namedSection
       "end": 28
   },
   "source": {
       "@type": "SpecificResource",
       "selector": {
           "@type": "FragmentSelector",
           "value": "namedSection",
       },
      "source": {
          "@type": "SpecificResource",
          "selector": {
              "@type": "foo:PageSelector",
              "value": "desiredPage",
           }
          "source" {
              "@type": "SpecificResource",
              "selector": {
                  "@type": "foo:QuerySelector",
                  "value": "knownItem",
              }
              "source": "http://example.org"
          }
      }
   }    
 }

Now, while the structure that Hugo (and others) has proposed looks 
more complex at first glance, the fact is that it is merely the 
inversion of the first. By making explicit use of the oa:hasSource 
property it has the added value that if at any time one of the 
selectors cannot be resolved for some reason or another one of the 
intermediary sources can still be rendered to the end user. Whereas 
the structure Rob has proposed provides only all or nothing 
functionality. Either I successfully apply all four selectors or I 
resort to the base source. It has no options for graceful failure.

@iherman I should note that this isn't spaghetti code. It doesn't even
 approach the definition for "spaghetti" and so I wish you wouldn't 
use such a pejorative term. It makes you sound dismissive rather 
engaged in the conversation (which I know isn't the case at all). Now 
you might argue that it's less intuitive but that's true for most 
inverted structures. Functionally this behaves precisely the same way 
as Rob's proposed pattern. Other than the option for providing 
graceful failure points through intermediate resources I don't see any
 difference between the two proposals. They're both better than what 
we have and I believe the crux of the debate should probably revolve 
around what is going to best for the end user -- "all or nothing" or 
"we got you half way there".

+1 for both solutions (and we might consider employing both patterns 
since they are as similar as property/reciprocal property) with some 
ground rules for providing info on which has been employed 
(unfortunately json doesn't have a way to include remarks; pretty 
extreme minus in my book but I digress and don't want to start a 
documentation soap box -- apologies).

And apologies all for the tl:dr. 

Regards,

Jacob


-- 
GitHub Notification of comment by jjett
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/93#issuecomment-173962602
 using your GitHub account

Received on Friday, 22 January 2016 16:05:05 UTC