{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/web-annotation/issues/110","labels_url":"https://api.github.com/repos/w3c/web-annotation/issues/110/labels{/name}","comments_url":"https://api.github.com/repos/w3c/web-annotation/issues/110/comments","events_url":"https://api.github.com/repos/w3c/web-annotation/issues/110/events","html_url":"https://github.com/w3c/web-annotation/issues/110","id":117965262,"number":110,"title":"Make Selectors available for the wide world?","user":{"login":"iherman","id":520723,"avatar_url":"https://avatars.githubusercontent.com/u/520723?v=3","gravatar_id":"","url":"https://api.github.com/users/iherman","html_url":"https://github.com/iherman","followers_url":"https://api.github.com/users/iherman/followers","following_url":"https://api.github.com/users/iherman/following{/other_user}","gists_url":"https://api.github.com/users/iherman/gists{/gist_id}","starred_url":"https://api.github.com/users/iherman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/iherman/subscriptions","organizations_url":"https://api.github.com/users/iherman/orgs","repos_url":"https://api.github.com/users/iherman/repos","events_url":"https://api.github.com/users/iherman/events{/privacy}","received_events_url":"https://api.github.com/users/iherman/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/web-annotation/labels/functionality+","name":"functionality+","color":"009800"},{"url":"https://api.github.com/repos/w3c/web-annotation/labels/model","name":"model","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-11-20T04:53:19Z","updated_at":"2015-11-20T18:25:27Z","closed_at":null,"body":"Selectors (and its subclasses) are very powerful. I can envisage other applications needing something similar. Actually, similar in two different ways: either as they are, as a description to select part of a resource; or to have a powerful fragment ID that can express the Selector concepts.  \r\n\r\nCan we make steps for reuse of these specifications without disturbing too much our work? Here are the alternatives I see.\r\n\r\n1. Separate the Selectors' part into a separate namespace. The oa namespace would be used for what is really annotation specific, and we could have the \"select\" (or whatever) namespace for the Selector class and all its subclasses. This change would affect only the RDF document, obviously, as well as the JSON-LD `@context` file. It would be invisible for the pure JSON-LD usage and document.\r\n2. Separate the Selectors' section (essentially 4.2 in the current model document) into a document on its own. I believe that this is only really necessary for the separate JSON document, the RDF document can stay as it is if we also adopt (1) above (RDF people are used to using part different vocabularies or part of an existing vocabulary).\r\n3. Define a fragment ID that reflects the current selectors.\r\n\r\nI think that (1) and (2) are just minor editorial changes that we can do easily. The only downside of (1) is that it may be a strong departure from the Community Group document; I am not sure whether it is indeed a big issue.\r\n\r\nWhat I meant for (3) is to define something like:\r\n\r\n```\r\nhttp://www.ex.org/ex.html#selector(type=TextQuoteSelector,exact=\"anotation\",prefix=\"this is an\",suffix=\"that has some\") \r\nhttp://www.ex.org/ex.dt#selector(type=DataPositionSelector,start=\"4096\",end=\"4104\") \r\n```\r\n\r\netc. It may be relatively easy to mechanically define these things based on the document we would produce anyway. However, it does raise issues related to the standard definition of fragment ID-s. However, even if we do not do it in this Working Group, by doing (1) and (2) we would facilitate other groups (Community or Working Groups) to pick this up."},"comment":{"url":"https://api.github.com/repos/w3c/web-annotation/issues/comments/158482382","html_url":"https://github.com/w3c/web-annotation/issues/110#issuecomment-158482382","issue_url":"https://api.github.com/repos/w3c/web-annotation/issues/110","id":158482382,"user":{"login":"jjett","id":4933420,"avatar_url":"https://avatars.githubusercontent.com/u/4933420?v=3","gravatar_id":"","url":"https://api.github.com/users/jjett","html_url":"https://github.com/jjett","followers_url":"https://api.github.com/users/jjett/followers","following_url":"https://api.github.com/users/jjett/following{/other_user}","gists_url":"https://api.github.com/users/jjett/gists{/gist_id}","starred_url":"https://api.github.com/users/jjett/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jjett/subscriptions","organizations_url":"https://api.github.com/users/jjett/orgs","repos_url":"https://api.github.com/users/jjett/repos","events_url":"https://api.github.com/users/jjett/events{/privacy}","received_events_url":"https://api.github.com/users/jjett/received_events","type":"User","site_admin":false},"created_at":"2015-11-20T18:25:27Z","updated_at":"2015-11-20T18:25:27Z","body":"Agree with @tilgovi and @BigBlueHat . +1 on 1 and 2. \r\n\r\nIIRC I mentioned that I have a use case for selectors outside of the annotation domain. Having finally crawled out from my school work rock, let me see if I can coherently articulate what that use case is.\r\n\r\nThe HathiTrust Digital Library is the public facing access point for the Google Digitization Efforts. It is a very large scale digital repository with over 14 million digitized books comprising several billions of pages. One of the ongoing questions is how to provide some form of access (or psuedo-access) for digital humanities researchers to the corpus for the purposes of computational analysis (for extracting features, modeling topics, etc.). Because 2/3rds of the corpus remains within the domain of copyright we've had to develop a specialized container called a workset[1]. The primary feature of the workset is that it provides a method for researchers to aggregate objects for analysis (see Figure 1). It also records a certain amount of metadata describing the aggregation as a whole (see Figure 2).\r\n\r\nFigure 1: Basic HTRC Workset Model\r\n![image](https://cloud.githubusercontent.com/assets/4933420/11307725/9f2fb850-8f7f-11e5-8f94-b1b5e88e763f.png)\r\n\r\nFigure 2: Full HTRC Workset Model\r\n![image](https://cloud.githubusercontent.com/assets/4933420/11307763/ceb72356-8f7f-11e5-9abf-30fa27bcce6c.png)\r\n\r\nThe nature of the HTRC's current architecture limits what can be gathered into worksets to just a notional thing called a volume (which is itself an aggregation of some pages with metadata describing the aggregation). Our scholarly users want us to move beyond notional volumes and provide them with tools that let them aggregate finer grained objects of interest into their worksets. The want to gather together specific pages or features on pages rather than whole volumes so that the data preparation overhead can be reduced and previous feature extraction work can be fully leveraged.\r\n\r\nSpecific Resources and Selectors (and the other specifiers) provide a very, very good way of doing this exact thing. These things would provide us a method for selecting specific portions of page(s), e.g., a scholar wants to analyze the text of a collection of poems, each poem is named as a specific resource and the selectors provide the architecture with a relatively simple means of cherry picking just the poem's text off of the page and feeding it into the analysis algorithm.\r\n\r\nAs you can see, this is not an *annotation* use case. So again +1 to suggestions 1 and 2 but moreover -1 to any language that is going to peg specific resources and selectors/specifiers to something specific to annotations. This latter thing will put me in the awkward position of plagiarizing/reinventing specific resources and specifiers for the HTRC's workset context.\r\n\r\nRegards,\r\n\r\nJacob\r\n\r\n[1] Additional information on the workset data model can be found at: http://hdl.handle.net/2142/78149 \r\n\r\n\r\n\r\n\r\n_____________________________________________________\r\nJacob Jett\r\nResearch Assistant\r\nCenter for Informatics Research in Science and Scholarship\r\nThe Graduate School of Library and Information Science\r\nUniversity of Illinois at Urbana-Champaign\r\n501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA\r\n(217) 244-2164\r\njjett2@illinois.edu"}}