Documentation missing/needed

[pstoehr]

The description of the details response formate shows that the JSON-object being returned consists of a documentBadge which is an array of information pieces. Each of these elements consists of four key-value-entries. As id, uri und provider are part of the getDetails-command the detail--entry seems to be the interesting part. Unfortunately the wiki-article "[21.09.2015] Request and Response format" has no information about the structure of detail-part. A short description would be helpful!

[pstoehr]

To clarify the issue above. Some of the results returned by the PP lead to closed-source documents.

For example the URI returned within this documentBadge {  "documentBadge": [    {      "provider": "Wissenmedia",      "id": "sl23519766",      "detail": {        "eexcessProxy": {          "edmlanguage": "de",          "dcidentifier": "sl23519766",          "edmpreview": "http:\/\/service.wissens-server.com\/wissensserver\/media\/?a=v&c=file-system&v=ws-mediensuche&reswidth=98&resheight=98&width=100&height=100&origin=center&border=1x1&background=FAFAFA&bordercolor=ddd&u=jadis\/incoming\/STW_277.jpg",          "dctermsdate": "2015-06-01T05:03:14Z",          "wgs84lat": "49.4277868790933",          "dcdescription": "KaiserslauternKaiserslautern,\u00a0kreisfreie Stadt und Verwaltungssitz des Landkreises Kaiserslautern, Rheinland-Pfalz, 233\u00a0m\u00a0\u00fcber dem Meeresspiegel, an der Lauter, am Nordwestrand des Pf\u00e4lzer Waldes, 97\u00a0200 Einwohner;\u00a0Technische Universit\u00e4t...",          "dctitle": "Kaiserslautern",          "edmeuropeanaProxy": "false",          "wgs84long": "7.77916608423087"        }      },      "uri": "http:\/\/service.wissens-server.com\/wissensserver\/view.html?a=t&r=CURRENT&i=sl23519766&s=BEP&v=eexcess&w=EEXCESS"    }  ],  "queryID": "234086972" }

can only be accessed if the user has an login at wissens-server.com.

A client-software that tries to fetch the URI has to interpreted the message returned by wissens-server.com to find out that this document is not freely accessible.

It would be helpful if the PP would return this piece of information within the detail-part of the documentBadge.

[chseifert]

This is related to https://github.com/EEXCESS/gdocs-plugin/issues/36 (user-centric view on google docs plugin). The core question (apart from the documentation issue), is how we handle closed sources

• Solution1: leave it as is it and live with annoyed users
• Solution2: never return closed sources unless they are explicitly requested in the source selection part of the request (this leads to an inconsistencyin the API, behavior not intuitive unless I know what the closed sources are)
• Solution3: change the API accordingly, add key for requesting closed sources (we shouldn't do this before the October deployment)
• Solution4: remove all closed sources (as nobody is going to use them - we do not have processes covering the "how to I subscribe to closed content part")

Michael, this is something we need to discuss "globally" - could you comment your view (I assigned you this issue)

[mgrani]

I would opt for solution 2 until the deployment and then change the api to a better solution. Simply because i dont want to change the api now (but in the next iteration).

In the next iteration we need to move on to a better, more transparent solution (E.g. a flag for return non-open access content)

[chseifert]

As discussed in the hangout, closed sources will be removed completely (Thomas agreed to take care of this)

[mgrani]

In addition, we will discuss a better solution at the next meeting. meanwhile topic closed