Dylan conway

T31 Telco May 17th 2013

Iosif, Michael, Fenareti (NTUA)
Philip (Betabond)
Meletis, Timotheos (Velti)
Suzana, Beatriz (CGI)

Iosif made a presentation: http://gitlab.openi-ict.eu/openi/tree/master/Partner%20Teleconferences/T3_1%20-%20OPENi%20APIs%20Specification/2013_5_17

Iosif started with an overview of the decisions that have already done for the project. Th

Quick presentation of graph api generic rules and activity API in redmine: http://redmine.openi-ict.eu/projects/openi/wiki/Graph_API_Generic_Rules

  • Outline of the decisions already made regarding the api design:
  • The Generic APIs are designed under a Graph API (how we access data, not how we store or analyze them)
  • It is REST/JSON and only
  • We have a universal, uniquely indexed object
  • We have minimum properties (id, url, objectType, service)

  • Iosif's presentation continues on graph rules and data modeling:

  • We have predefined sets of properties (object profiles, location, time, duration, address)
  • Additional references with objects (e.g. place, comment) or properties (e.g. location) that create a context for the object, and are created after the object initialization are considered Contextual Data
  • Storing, editing and deleting contextual data, are under the Context API
  • Contextual Data are delivered under the Graph API to the developer

Beatriz asks about the profile properties if they are fixed and how i can define new properties or leave blank some.
Iosif shows the media API and photo. The photo has the basic properties and the developer should already know who are they. If someone needs new ones he can declare them in propery tag. Every object has the minimum subset of properties that are agreed as the most important.

Timos agrees with the above and has a question on fixed properties and if everyone can access those and search on them. The 3rd party service can declare new properties and those will be beyond the basics and searchable by everyone. Iosif agrees here.

  • Iosif presents the main differences and new approach of this week regarding the api.
  • OPENi has no social rules: I can ask only for the authorized user through the Graph API (not 100% decided)
  • Other predefined properties can be grouped under a special “properties” tag (e.g. width, height) (not 100% decided)
  • A user may have only one Cloudlet: the Cloudlet Account manages and is hierarchically over CBS Accounts

Iosif asks feedback and comments.

Suzana asks about their redmine contribution. Iosif says Michael is about to send an email on service enablers feedback and comments.

Timos comments on activity API and activity objects. Those activities have contextual data that needs to be clarified and discussed.
Questions from Timos
1) how many profiles a user could have compared to the cloudlet account
2) the new schema would only be available to the developer who creates, or generally he could publish this to make it available for anyone interested?

Iosif answers that there will be a central cloudlet profile and all the rest will be 1-1 linked to that.
To the second question says that needs to be discussed. Not yet decided. At the moment we consider that the developer can create contextual properties, controlled by the developer, textual only, as we have already shared. But there is a dependency with the rest concept of the Cloudlet.

Beatriz asks if they expect contribution by Logica on cloudlet api. Iosif answers that the cloudlet is going to change, we expect contribution from TSSG or FOKUS but there is no feedback yet. There is a dependency here.

Timos takes the presenter screen and starts presenting their contribution on redmine regarding context API: http://redmine.openi-ict.eu/projects/openi/wiki/Context_API
Timos asks for feedback. Iosif has questions. He identifies that there are duplicate properties that may be Grouped He also suggests that some contextual data could be updated automatically and some through the developer based on the specific application. Timos agrees.
Should we describe read write permissions? Timos suggests we do that later.

Meletis describes the 4 methods in the context api. Iosif makes a remark to fix the API path to have a Graph structure, and move properties to the call and not the path.

Logica says they do not need to present anything yet, and they continue working on service enablers api. Iosif says that they generally need to work on the apis with detailed methods, and that NTUA will send comments.

The next meeting will run on Friday 24th to get prepared for the London meeting.


Related

Wiki: WP3 Telco Minutes