search

w3c / wpub-ann

Web Annotation Extensions for Web Publications
https://w3c.github.io/wpub-ann/
Other
6 stars 10 forks source link

Frag ids - source vs. scope #22

Closed tcole3 closed 7 years ago

tcole3 commented 7 years ago

There is a natural inclination to consider the more granular resource as the source and the containing resource (say a Web Pub) the scope. Thus:

JSON: 
{
    "scope": "https://dauwhe.github.io/html-first/MobyDick.wpub",
    "source": "https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html",
    "selector": {
        "type": "TextQuoteSelector",
        "exact": "Call me Ishmael"
    }
}

But might this also be correct?

JSON: 
{
    "source": "https://dauwhe.github.io/html-first/MobyDick.wpub",
    "scope": "https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html",
    "selector": {
        "type": "TextQuoteSelector",
        "exact": "Call me Ishmael"
    }
}

This selector is saying that somewhere in the Web Pub, you'll find the phrase "Call me Ishmael", which arguably seems correct (intellectually) although it may require you to read a bunch of Web Publication Resources to get there in the end. Or, if we agree the second serialization is incorrect, then we may want to say so, especially if we use fragment ids (issue #6) to avoid the possibility of someone wanting to do the following:

https://dauwhe.github.io/html-first/MobyDick.wpub#selector(
    type=TextQuoteSelector,
    scope=hhttps://dauwhe.github.io/html-first/MobyDickNav/html/c001.html,
        exact=Call me Ishmael
)

The temptation of course is that this url makes it particularly easy to collate locators by Web Publication identifier rather than component file URL. Of course another option is to interpret the base url of the fragment as the scope and require the inclusion of an explicit source within the fragment. for example:

https://dauwhe.github.io/html-first/MobyDick.wpub#selector(
    type=TextQuoteSelector,
    source=hhttps://dauwhe.github.io/html-first/MobyDickNav/html/c001.html,
        exact=Call me Ishmael
)

Either of the last 2 approaches means that the user agent will need to get the resource identified within the locator to actually resolve the locator. Retrieving the base url alone is not sufficient.

tcole3 commented 7 years ago

related issue #4 This issue is now closed, but I'm not sure we fully considered our options here on this specific way of including source / scope in fragment ids. May also impact on on how we fix multi-resource selectors...

tcole3 commented 7 years ago

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