Re: anno-ACTION-29: Create draft proposal for rendering state/selector

> On 16 Nov 2015, at 23:14, Benjamin Young <bigbluehat@hypothes.is> wrote:
> 
> This one's been on my list for awhile, and I've dug into the space several times, and here (at last) is the output.
> 
> I dug through the following vocabularies:
>  - prov-o:SoftwareAgent
>  - dcterms:Software
>    - we already include `dcterms` as a prefix
>  - foaf:Agent
>    - `foaf` is also included already
>  - doap
>    - https://github.com/edumbill/doap/wiki/JSON-LD-@context-for-package.json <https://github.com/edumbill/doap/wiki/JSON-LD-@context-for-package.json>
>    - non-normative afaik
>    - context doc is incomplete (at best), but DOAP is used at Apache & PyPi among others
>  - schema.org <http://schema.org/>'s SoftwareApplication
>    - by far the most thorough that I looked into
>    - according to some chats at TPAC, we can reference them now/soon
> 
> PROV-O has the right terminology in the form of `prov:qualifiedUsage` and it's `prov:Usage` class. Schema.org's schema:SoftwareApplication (and possibly schema:WebApplication) include a couple properties (and perhaps a few others) which are clearer in their specification than `dcterms`, `foaf`, etc. More info below.
> 
> Here's an example of what I'm thinking based on the above--I'm using full CURIE names for the new keys. The other's are specified in http://www.w3.org/ns/anno.jsonld <http://www.w3.org/ns/anno.jsonld>
> ```
> {
>   "type": "Annotation",
>   "target": {
>     "type": "SpecificResource",
>     "source": "http://example.com/ <http://example.com/>",
>     "selector": [{...}, {...}],
>     "prov:qualifiedUsage": {
>       "type": ["prov:Usage", "prov:EntityInfluence"],
>       "prov:entity": {
>         "id": "https://github.com/mozilla/pdf.js/releases/tag/v1.1.114 <https://github.com/mozilla/pdf.js/releases/tag/v1.1.114>",
>         "type": "Software",
>         "name": "PDF.js",
>         "schema:softwareVersion": "1.1.114",
>         "schema:browserRequirements": "HTML5, CSS, JavaScript"
>       }
>     }
>   },
>   "generator": {
>     "type": "Software",
>     "name": "Hypothes.is",
>     "homepage": "http://hypothes.is/ <http://hypothes.is/>"
>   }
> }
> ```
> 
> What I'd like this to end up looking like, however, is this example:
> ```
> {
>   "type": "Annotation",
>   "target": {
>     "type": "SpecificResource",
>     "source": "http://example.com/ <http://example.com/>",
>     "selector": [{...}, {...}],
>     "renderedVia": {
>       "id": "https://github.com/mozilla/pdf.js/releases/tag/v1.1.114 <https://github.com/mozilla/pdf.js/releases/tag/v1.1.114>",
>       "type": "Software",
>       "name": "PDF.js",
>       "softwareVersion": "1.1.114",
>       "browserRequirements": "HTML5, CSS, JavaScript"
>     }
>   },
>   "generator": {
>     "type": "Software",
>     "name": "Hypothes.is",
>     "homepage": "http://hypothes.is/ <http://hypothes.is/>"
>   }
> }
> ```
> 
> Turning the `prov:qualifiedUsage a prov:Usage; prov:entity` chain into just `renderedVia` (or similar) is beyond my physic.

I would be worried about bringing prov into this. There is relatively complex model behind the Provenance ontology[1], and trying to fuse these things seems to be way more than what we need.

[1] http://www.w3.org/TR/2013/REC-prov-dm-20130430/ <http://www.w3.org/TR/2013/REC-prov-dm-20130430/>
> 
> Is something like that even possible? If that's not, then I propose we define `renderedVia` to mean essentially that--the usage of this SpecificResource (in this case that target source + this selector list) is qualified by the use of this rendering system...such that these selectors may not work if the rendering scenario is different.

I think that doing partially ourselves, and use either Schema and/or DOAP terms is way enough for what we need. Let us try to keep it simple.

My only problem with DOAP is that it is not really maintained by anyone right now. Last time I talked to Edd Dumbill seemed to suggest that he had moved on; the repo has not been touched for years. That being said, there is a decent deployment of his terms, so this is a possibility.

There are some projects (I would have to dig them out) that are concerned about the scholarly references of software which could be used here, but I would not think we should spend too much energy into this. Users/implementations may use their own vocabularies if we just provide some sort of elementary scaffolding: that is all we need to do imho. Ie, more or less what you have in the example above with name, homepage, software versions, maybe 1-2 terms more, and stop there…

Ivan

> 
> I toyed (for a bit) using prov:qualifiedDerivation, but that seemed to require stating more about this new generated resource (the PDF.js representation of the resource referenced by the `target`) rather than about the `SpecificResource`--such as "when you use this SpecificResource you should care about this situation" vs. "hey look! PDF.js made a new thing out of this other thing...and you should care." Especially given that things like Text Quote Selector are pretty resilient (assuming only the structure of the document changes between format vs. the content) such that this "qualified usage" may or may not be of value to the consumer of the annotation for it's own rendering / display of the document + the annotation.
> 
> Regardless of which terms we use or what we call the key, the best place I could find to put it was as a property on `SpecificResource` as having it on the annotation (as generator is) sends the wrong message about what's effected by this information.
> 
> Also, `renderedVia` seemed more correct than `hasRenderer`.
> 
> Thoughts welcome!
> Benjamin
> --
> Developer Advocate
> http://hypothes.is/ <http://hypothes.is/>
> 
> On Wed, Oct 21, 2015 at 11:36 AM, Web Annotation Working Group Issue Tracker <sysbot+tracker@w3.org <mailto:sysbot+tracker@w3.org>> wrote:
> anno-ACTION-29: Create draft proposal for rendering state/selector
> 
> http://www.w3.org/annotation/track/actions/29 <http://www.w3.org/annotation/track/actions/29>
> 
> Assigned to: Benjamin Young
> 
> 
> 
> 
> 
> 
> 
> 
> 


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704