frag ids - whither scope

[tcole3]

In the Web Anno data model, 'scope' and 'source' are properties of the SpecificResource or what we are calling the Locator. They are not properties of selectors or states (or positions). But when translated to a fragment, we include scope within the selector(...), state(...) and position(...). There are good reasons for this (e.g., it is more succinct than some options and may be the more intuitive), but are there unintended negative consequences of doing this? For instance consider Example 3:

JSON: 
{
    "scope": "https://dauwhe.github.io/html-first/MobyDick.wpub",
    "source": "https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html",
    "selector": {
        "type": "CssSelector",
        "value": "#elemid > .elemclass + p"
    }
}

The equivalent frag id we have (Example 24, with line breaks for readability) looks like this (option 1):

https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html#selector(
    type=CssSelector,
    scope=https://dauwhe.github.io/html-first/MobyDick.wpub,
    value=%23elemid%20>%20.elemclass%20+%20p
)

There are other options, but perhaps less intuitive / more difficult to explain? e.g. (option 2):

https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html#
        scope=https://dauwhe.github.io/html-first/MobyDick.wpub&
        selector(
    type=CssSelector,
    value=%23elemid%20>%20.elemclass%20+%20p
)

If we decide we need frag ids and scope (issues #6 and #10 ), we need to make sure we have consensus on this issue. One advantage of the Option 2 is that it avoids temptation to add scope to a selector, state or position that is used to refine. I think having scope on a refinement but not on the top-level (first in hierarchy) selector, state or position would cause problems.

[tcole3]

Another option (3) is to add locator(...) to the current selector(...), state(...), position(...) options for the fragment identifier. This would allow us to better preserve nested functional syntax This might be even more useful to the way we are thinking of multi-resource / multi-locator use cases and for use cases where we simply want to associate the scope relationship with a component resource (aka a Web Publication Resource) and do not need to select a range, state or position:

https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html#locator(
        scope=https://dauwhe.github.io/html-first/MobyDick.wpub,
        selector(
       type=CssSelector,
       value=%23elemid%20>%20.elemclass%20+%20p
        )
)

and when all you want to express is a scope:

https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html#locator(
        scope=https://dauwhe.github.io/html-first/MobyDick.wpub)

which corresponds to the following JSON, see target in example 37 in the Web Anno Data Model

{
   "source": "https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html",
   "scope":  "https://dauwhe.github.io/html-first/MobyDick.wpub)"
}

[iherman]

Trying to keep the complexity low, I am not very much in favor of your third option, ie, to use #locator and the a selector inside. I do not expect scope to be used frequently, i.e., in most of the cases it would be an overkill.

However, I like your option 2, ie, something like:

https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html#
        scope=https://dauwhe.github.io/html-first/MobyDick.wpub&
        selector(…)

This makes it indeed clearer.

I have not changed the spec for now, but I linked to this issue. The issue may be indeed moot if we decide not to use frag id-s in the first place...

[tcole3]

Closed in anticipation that locator to fragment id translation will be removed from the draft spec (which will then moot this issue). See issue #6.