Including resource previews in annotations

[gsergiu]

The presentaion of Annotations (in client applications) to end users needs to be based on human readable information insted of URIs. For example, when the Resources of some Annotation include the following Wikidata URI
https://www.wikidata.org/wiki/Q43715, at least the name of pe person (in this case "Vlad Tepes"), and eventually a depiction ( in this case https://commons.wikimedia.org/wiki/File:Vlad_Tepes_coloured_drawing.png) should be displayed to the end users.

The generation of "previews" needs to be performed at creation time, either by client or by server, so that the retrieval of annotations and presentation of annotations should require only one http request. (This is especially important for annotations with multiple bodies and/or multiple targets)

The current specifications doesn't make any recommendations about how to include these previews in the Annotation serialization, even if the dc and foaf namespaces are already included in the @context

1 . One possibility of including the previews is to embed them in the Resource Serialization like:

"body": {
    "id": "https://www.wikidata.org/wiki/Q43715",
    "format": "text/html",
    "dc:title": "Vlad Tepes - Wikidata"
  },

and

"body": {
    "source": 
         { 
           "id" : "https://www.wikidata.org/wiki/Q43715",
           "format": "text/html",
          "dc:title": "Vlad Tepes - Wikidata"
       },
       "purpose" : "tagging"
  },

respectively.

2 . Another posibility that would reduce verbosity is to use an own field for resourcePreview(s), like

"body": {
       "source":  "https://www.wikidata.org/wiki/Q43715",
        "purpose" : "tagging"
  },
 "resourcePreview": 
         { 
           "id" : "https://www.wikidata.org/wiki/Q43715",
           "format": "text/html",
          "dc:title": "Vlad Tepes - Wikidata"
       },

(PS: I didn't check the full syntactic correctness from the RDF perspective, but this can be done when the functionality is accepted for integration in the specifications)

So ... the two questions I have:

1. Can this functionality be included in the specifications before the CR?
2. Which should be the recommended way of adding previews, the option 1, the option 2 or both?

Br, Sergiu

[iherman]

The data model indeed does not deal with the ways implementation interact with the user, including the way the information is presented. This feature of the spec was, I believe, deliberately chosen as a separation of concerns.

I would be very uneasy opening this issue at this point (let us remember that we are planning for CR, which also means a feature freeze). Finding a consensus on what the best way is to encode this feature, what other, UI specific features could/should be available (e.g., how do I control the presentation of an annotation that the data model includes as pure text?), etc, is not something we can decide at this point. If there is a consensus that the data model should include UI specific features, that is definitely a version 2 issue.

My proposal is to postpone this issue for version 2.

[gsergiu]

I understand your concerns regarding the CR. However, my claim is that this is a "mandatory" functionality for implementations. This means, that each implementation will need to extend the annotation serialization in a way that is not standardized. I don’t know if a compromise solution can be adopted, by adding a non-normative annex in the standard, or a reference to long living document in which the community can address open issues and propose/discuss solutions. I think this would be benefic both for community and the V2 of the standard

[iherman]

On 3 Jun 2016, at 11:41, gsergiu [email protected] wrote:

I understand your concerns on the CR. However, my claim is that this is a "mandatory" functionality for implementations. This means, that each implementation will need to extend the annotation serialization in a way that is not standardized.

All implementations have to do something like that. Correct. But there is not necessarily a need for having an interoperability around this feature; it may be the point where implementations compete. I say may, because that is an issue where it would take some time finding a consensus on. I don’t know if a compromise solution can be adopted, by adding a non-normative annex in the standard, or a reference to long living document in which the community can address open issues and propose/discuss solutions. I think this would be benefic both for community and the V2 of the standard

Having a living document, in more general manner, on implementation experiences and possible V2 features is a good idea in any case. We will have to have a discussion, when the time comes, to set up some sort of a 'life after Rec' mechanism exactly for these purposes. This is a clear possible topic.

But, for now, I would propose to set this issue as postponed.

[azaroth42]

+1 to postpone -- we don't know what information is required for clients to display a preview yet, and we can both find that out and already implement it via extensions.

[iherman]

Discussed on 2016-06-03, resolved to postpone

See: http://www.w3.org/2016/06/03-annotation-irc#T15-38-44

[gsergiu]

It is ok for me to postpone the solution for this issue ... just that I think that a note referencing the "overview/index" of the living documents should be included in the CR. For now we already identified 2 Topics to be addressed in this way, #257 and #248

[iherman]

In view of the last comment from @gsergiu, shouldn't a reference be added to the CR? Ie, should this issue be added to the "V1 CR" milestone? @azaroth42 ? @tcole3

[gsergiu]

Just a reference for further use. The wikimedia/wikidata developement made a good progress in this direction in the last year. The requested resource previous are the equivalent of wikidata/wikimedia infoboxes https://meta.wikimedia.org/wiki/Wikidata/Infoboxes