Meeting minutes
prev minutes
<dape> https://
Daniel: very short
… we talked about vacation plans and open issues that could be discussed during the F2F
… moreover we discussed about securityDefinitions and how they are configured in node-wot
… minor typo at the end of the minutes
… any other problems?
Daniel: minutes approved
quick updates
Daniel: last time we proposed a shorten procedure to approve the minutes, just to gain more time during the calls
… not sure who proposed it
… the idea is to ask to everyone to review the minutes beforehand
Zoltan: yes because usually the critical side is the approval not the reviewing process
Daniel: I like the idea
… even if it is different from the other Task Forces
… kaz has the final word
Kaz: yes, that would be ideal
Daniel: ok
Zoltan: we can include the link to an announce about the next meeting
… maybe kaz email about pubblication is enough
Daniel: not sure
… we'll duplicate the content, kaz email should be ok
Zoltan: ok
Critiano: +1 for the new procedure
Zoltan: we would gain 5 to 10 minutes per call
Daniel: yeah, usually the minutes are very short
Daniel: mizushima?
Mizushima: ok
Kaz: this implies that daniel would review the minutes beforhand
<dape> PROPOSAL: Previous minutes are to be read before the meeting. Concerns are to be raised in the beginning of the call. Minutes will be mainly approved in the beginning call.
Resolution: Previous minutes are to be read before the meeting. Concerns are to be raised in the beginning of the call. Minutes will be mainly approved at the beginning of each call.
vacation plans
Daniel: please let us know if you are planning any weeks out
… it seems that the other calls will have cancellation but I have available most of the time.
test fest and virtual F2F
Daniel: it would be useful to try to summarize any relevant topics about scripting api
<dape> CA: Discovery does not require to report a TD
<dape> ... it can be anything else
<dape> DP: What is expected to be get?
<dape> CA: Part of TD
<dape> ... filter or selection
Daniel: can we say that in our use case we require to return a full TD?
Critiano: yeah we can reduce the possible queries types
Zoltan: we should start from use cases
… it would be reasonable to start from full TDs
Daniel: so the consequence for us it to forbid partial fetching
Zoltan: we already have general purpose fetching machinism
Critiano: we can limit query syntax and check the return types
Zoltan: we need demos for partialTD
… try to build the whole use-case (end-to-end)
Daniel: if we extend later it might break later on
Zoltan: we can use a different function to return "anything"
Critiano: we could start from limiting queries syntaxes and see how it would work for the implementation
Daniel: we used to have a query field in the ThingFilter
Zoltan: we could re-introduce
Daniel: having jsonPath and SPARQL in the same object (ThingFilter would be odd)
Zoltan: we can have enum specifing the query type
Daniel: I would support it
Critiano: it is like using functions
Zoltan: I would expirement with both
Critiano: can we limit query syntax?
Zoltan: that's a difficult question, we will write algorithms for sure... how they will look like?
Daniel: the easiest algorithm would be accept any query and try to map the result to a thing description, fail if not possible
Zoltan: I want to keep it practical so we should go trough valid use cases.
… do it small things and well
Critiano: we have two options right now: 1. use the api just to get a TD and then interact with the TDD 2. provide a more user friendly api that interact with the TDD transparantly
Daniel: Option 1 seems reasonable
… but I feel biased, any other opionions?
Zoltan: I would leave the current discovery api simple and then make an experimental api for Thing Directories
Daniel: is there a definitive border between the twos?
Zoltan: we can introduce an experimental entry point for Thing Description Directories.
Daniel: we can ask for feedback
Zoltan: expiremental vs stable api is easy to do right now
issues
Daniel: please check issue 327
… we need to discuss next week or in the issue
Kaz: W3C Process requires us to provide implementations for REC Track specifications, we need to make this clear
Daniel: running code is required, thank you for feedback
… ok out of time adjourned
<kaz> [adjourned]