Correct format for "timestamps"

[pstoehr]

Generating a query allows to submit information about the person that is creates the query. Beside the name a "birthDate" an a piece of information about the current location can be provided.
In both case a timestamp can be provided using an int-value.
Unfortunately, there is no clear description how these int-values have to be used.

Is there any additional document available?

Thanks
Peter

[chseifert]

We removed unnecessary attributes and/or too many details in attribute values. The new format is shown here
https://github.com/EEXCESS/eexcess/wiki/%5B21.09.2015%5D-Request-and-Response-format

(reference to the old format
https://github.com/EEXCESS/eexcess/wiki/%5Bcurrent%5D--Request-and-Response-format-for-call-to-federated-recommender-and-privacy-proxy)

Thomas, can you comment on when this will be deployed on the dev server?

[jr-dig-orgel]

we have yesterday afternoon the latest builds deployed to our dev-server

[ThomasCerq]

The birthDate is note used anymore. Instead, we introduced ageRange (0: child, 1: young adult, 2: adult). The names (first name and last name) are not used anymore.
Regarding the timestamp, I don't know what you mean exactly. Where have you seen it? If it's related to logging, you should not worry about it. The logging component will take care of it.

[pstoehr]

Hi *,

I've learned from the chseiferts posting this morning that the JSON-documentation at https://github.com/EEXCESS/eexcess/wiki/%5Bcurrent%5D--Request-and-Response-format-for-call-to-federated-recommender-and-privacy-proxy is out dated.
This old format had "userLocations" element that needs a "timestamp".

As the new JSON-objects (https://github.com/EEXCESS/eexcess/wiki/%5B21.09.2015%5D-Request-and-Response-format#query-format) don't have any usrLocations anymore the problem with "timestamps" seems to be solved.

Thanks
Peter

[ThomasCerq]

Actually, I think we'll have an attribute userLocations in the next version. I removed it from the current version but Christin told me that we're going to use it at some point. Before I introduce it back, I'd like to know if it's different from Location (City + Country; explicitly provided by users). Will it be used in a different way? I looks to me that it's a bit redundant. We should decide which one to keep.

[chseifert]

Sorry, Thomas, there might have been a misunderstanding. We don't use the user location and don't plan to do it (the recommender does not know what to do with it anyway). What we do is to extract location information from the text (e.g, the city "Passau" was mentioned), and add it as a location to the context keywords (entity type information for each keyword).

[pstoehr]

If the user location isn't used anymore, what is the use of the "address" element of the Federated Recommender /recommend-JSON-Object? The documention says that it is the "Address of the User".

Should this element be used to describe the current location of the user or should it be used in the way chseifert mentioned it in the comment above?

[ThomasCerq]

Ok, I probably misunderstood it indeed.

Regarding the address, it should not be used as Christin mentioned (the location of the user and the content are (most of the time) not related). The idea was to use it to recommend (or rank recommendations) according to the location of the user. For instance, if I live in Paris, a recommendation about Mona Lisa (which is located at Le Louvre) is even more relevant than if I lived somewhere else.
If it won't be used at all, I think we should remote it (the more simple for users, the better).

[chseifert]

I reassign to Hermann, to clarify whether the user location will be used or not on the federated recommender site. If we use it on the client for personalisation (Jörg), it would not be transferred to the server anyway. Thus, only the federated recommender guys can decide whether we should keep it or can remove it.