{"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":9,"created_at":"2015-11-20T04:53:19Z","updated_at":"2015-11-25T05:45:04Z","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/159498088","html_url":"https://github.com/w3c/web-annotation/issues/110#issuecomment-159498088","issue_url":"https://api.github.com/repos/w3c/web-annotation/issues/110","id":159498088,"user":{"login":"tilgovi","id":20818,"avatar_url":"https://avatars.githubusercontent.com/u/20818?v=3","gravatar_id":"","url":"https://api.github.com/users/tilgovi","html_url":"https://github.com/tilgovi","followers_url":"https://api.github.com/users/tilgovi/followers","following_url":"https://api.github.com/users/tilgovi/following{/other_user}","gists_url":"https://api.github.com/users/tilgovi/gists{/gist_id}","starred_url":"https://api.github.com/users/tilgovi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tilgovi/subscriptions","organizations_url":"https://api.github.com/users/tilgovi/orgs","repos_url":"https://api.github.com/users/tilgovi/repos","events_url":"https://api.github.com/users/tilgovi/events{/privacy}","received_events_url":"https://api.github.com/users/tilgovi/received_events","type":"User","site_admin":false},"created_at":"2015-11-25T05:45:04Z","updated_at":"2015-11-25T05:45:04Z","body":"Can you explain your claim that it is \"not trivial amount of work to have Selectors go through the process separately from the rest of the model\", Rob?\r\n\r\nIs there significant per-document overhead for publishing? Could that be mitigated through delegation or otherwise distributing the workload among more participants?\r\n\r\n---\r\n\r\nI agree that selectors aren't useful without a resource to select from, but the class of that resource is not necessarily our SpecificResource. For instance, it may be applicable to a domain where state is made superfluous by content-addressing."}}