See also: IRC log
<scribe> scribe: Yingying
<scribe> scribenick: yingying
Sebastian: we changed the call
time one hour earlier. Hope it would be more comfortable for
everybody to join it.
... hope the time be stable until the time shift in half a
year.
Sebastian: for https://github.com/w3c/wot/issues/307
issue 307
... I added two comments into it.
<inserted> Daniel: new comments should be on new repository
Victor: better to differentiate the IG and WG issues.
sebastian: binary encoding of
more compact version for TD. It would be good to have a
thorough evaluable for all the formats based on some UCs.
... it would be one of the next steps to look into. Now it's a
bit too early to pay too much attention on it.
<yingying_> scribenick: yingying_
sebastian: we need to have a more look at maria's again before next step.
<kaz> Maria's slides
Maria: some modification has been done on the model.
<kaz> (looking at slide 10)
Sebastian: You mentioned to use
current practice document to setup the model here. Maybe a bit
early.
... DataFormat is what we call output data
Maria: property can have 4 input value and 4 output value and tranformed to dataformat
Sebastian: TD does not include
the runtime data. This sounds like to have some runtime
data.
... you mentioned that you have some UCs on it. Could you share
the UCs for us to have more understanding on it?
Maria: Yes. My colleague Fernando is working on the implementation.
Sebastian: Currently we're thinking about JSON Schema for it. I'm not sure whether JSON Schema can support this.
Daniel: there is a field called default which could be used.
Sebastian: about UCs I think we could discuss later on. What's the difference of relative href and non-relative href?
<dape> reference how JSON schema uses default values, see http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.2
Maria: there is base href. You have to question whether this is different. Maybe an href is relative to the base href. So we need to figure out whether all the hrefs need to be calculated to the base href and combine them. otherwise you can just use the end point.
Daniel: href is aligned with the website does in current practice. It might be relative or absolute.
Victor: why another parameter is needed?
Fernando: I think we can reuse the same href property.
Maria: the relative href parameter only has the relative part. For the endpoint it is possible to need both.
Victor: if it happens that these
two are not compatible, what would you do?
... if I try to model the TD, I would rather use the same href
parameter.
Maria: it's useful when querying you don't need to do all the string matching.
Victor: it still makes sense to differentiate the two properties. I will add a comment on it and you can explain more on it.
Daniel: I understand that it is intended to be more efficient for search. It's an implementation problem. For the conception model, it's better to have only one href value.
Sebastian: relative definition composed with the base uri will be the final href.
Maria: you propose to use the same href as in current practice.
Sebastian: Yes just as the websites are doing.
Maria: I will have a look at the alternative.
Sebastian: Please don't
misunderstand us. We just want to understand the reason behind.
Maybe there is good reason for it which we would like to
know.
... we need to decide which kind of namespace need to use for
which type of vocabulary.
... If we need to define a new one or use the already existed
namespace. That's what we are discussing in the group.
Maria: I can provide you a new presentation. I combined all the questions into it.
(slide 4)
<inserted> reuse namespace for trusted ones.
Maria: wot predicates are object properties.
Sebastian: next question is that
in your model there is a differentiation of a virtual vs.
physical thing necessary.
... are there some examples? e.g. collection of all lights in
the room, etc.
... I'm not sure whether it's necessary to include it in the
model.
Fernando: raw data or geographic information(e.g. longitude and altitude), which means it makes sense to differentiation.
Daniel: I would not to make the differentiation. You might want to hide it's a physical or not. You might don't know whether it's physical or virtual.
Maria: there are things that you
want to represent as physical or virtual.
... for these cases we use the ThingEcosystemDescription.
... I don't know whether the diagram helps or makes it more
confused.
Daniel: it helps. But I would rather to keep it simple.
Sebastian: for example, I need a temperature value but I don't care whether it comes from a thermometer or a device.
Fernanda: an example is the GPS for navigation.
Maria: having the physical information is helpful to calculate the exact location.
Fernando: we are using it also to
provide the access mapping. It is useful.
... e.g. service provides information about air pollution,
things are not directly from device. We need to actually the
whole air pollution.
Maria: aligned with ISO IoT RA.
Sebastian: UCs will help us to understand the classification of physical things and virtual things.
Maria: On which use cases the
model rely on? See slide 6.
... which tool is used to setup the model? Open source? see
slide 7.
Sebastian: We discussed in last F2F meeting which tools to use to design TD model.
Maria: I do them manually.
... I tried some and not very good. So I do them manually.
Sebastian: Thanks a lot for
answering the questions and making presentation.
... are you also open to modify your model to incorporate some
of our conception?
Maria: Yes I am open to it. I'm happy to modify the ontology to fit you better.
Sebastian: what would be the process? Change request?
Maria: we can see the change request and discuss them in the github issues.
Sebastian: I will try to write
down some change requests and discuss within the group.
... I think no very big changes need to do.
... ten minutes overtime.
... thank you very much to Maria and Fernando!
... See you in next week.
[adjourned]