<kaz> scribenick: taki

<scribe> scribe: TK

Koster: Semantic API introduction is the topic
... Would like to go over TD model
... Maybe we can do that first.

Koster showing issue# 163...

<mjkoster> https://github.com/w3c/wot-thing-description/issues/163

<mjkoster> https://github.com/mjkoster/wot-protocol-binding/blob/master/SemanticAPI.pdf

Koster: I flattened TD, and made diagram
... connect data and property and dataschema.

Koster: property, action, evnet is connected to dataschema

<kaz> diagram

Koster: property directly exposes dataschema

Koster: TD has ontology, and UML-ish diagram.
... I would like to make sure if people are ok with it.
... property is a subclassof dataschema, we may need to think about this.

Victor: property is a dataschema, action and event are data specification.

Koster: data and data specification.
... what is the result of the difference?

Victor: it provides more information for data processing.
... property is an instance, action and event are specifications
... dataschema no longer exists.

Kaz: we are using #wot channel for this call.

Victor showing td.ttl...

<kaz> td.ttl

Victor: there is dataschema in td.tll.
... action has input and output, which are data specification.

Koster: data specification in turn relates to dataschema.

Victor: dataschema class is just for convenience.
... could be removed.
... data and specification are defined in another module.

Victor showing json-schema.ttl...

<kaz> json-schema.ttl

Koster: Is this the current files?

Victor: Yes.

Koster: Does this make sense to everyone?

Maria: subclass part. I have concern.
... property and event.

Victor: event should not a subclass of something.

Koster: we all seem to have agreed to that...

Maria: you do not need to extra classes wrt property.

Victor: I agree it is not required.

Danh: event is subclass of data specification?

Victor: it is temporary just for now.

Danh proposing new name...

Victor: Your help in modifying ontology is welcome, Dahn.

Danh: Is the model the one currently used in TD spec?

Victor: Yes

<DanhLePhuoc> TD Draft: https://w3c.github.io/wot-thing-description/

<inserted> More specifically: TD draft's "5. Information Model"

Koster: data specification is a JSON schema.
... data, property and specification. relationship between them... action and event are related to specification. specification is related to data.
... dataschema class may be redundant.
... specification is essentially a schema.
... input/output are data, right?

Victor: we can make invoked action, occurred event, those classes can be subclass of data.

Koster: input/output are enough.

Victor: we can describe how action was invoked through forms.

Koster: it does not have to desribe how it was invoked.
... data is described by schema.
... property is subclass of data.
... this is good thing, and make sense.
... specification is schema.

Maria: data schema has another URI. we have now three unrelated models.
... how can someone know security model has relatioinship with another?

Victor: bridge ontology.
... TD specification is W3C specification.

Maria: how can someone know you have to use three modules?
... where is the definition of "data" class?
... property is an instance of data.

Victor: data class will never be used in projects.

Maria: defined by modules. what is the benefit?

Victor: in the future, invoked action and occurred event can be related to data class.

Maria: property can be directly connected to data specification.

Victor: yes, you can.

Maria: "subclass" requires everyone to do in one manner.

Victor: "data" is just for future invoked action and occurred event, would align well with other ontologies.
... you do not need to include "data" in your RDF model.
... you ca still have connection between propety and specification.
... "data" isSpecifiedBy "specification".
... any invoked action has data.

Koster: invoked action and occurred event will be added to the graph, eventually?

Victor: Yes
... I need to spend some time to make sure there is no unintended impact.

<MariaPoveda> "Victor: you do not need to include "data" in your RDF model." -> it will be inferred using this model, can't avoid

Koster: RDF graph is for enrich information, not really for serialization.
... It was worthwhile to discuss this since most people involved in this discussion were present in this call.

Victor: One issue is Thing Description is described TD spec. I hope it won't confuse.
... I need to make sure how it aligns with SSN module.

Danh: schema.org in general tries not to be too strict.

Maria: Difficulty with SSN is that it still needs domain knowledge.

Danh: inconsistent model often become cause problems.

Koster: constraints vs. avoiding too much constraint needs balance.
... data and specification approach sounds like a right direction.
... Next call, Darko is out, but I suggest us to have a telecon.

<Zakim> kaz, you wanted to ask about the relationship between the TTL file (e.g., https://github.com/w3c/wot-thing-description/blob/master/ontology/td.ttl) and model diagram in TD draft, (2) table in TD draft and (3) this visualized structure on the screen

Kaz: relationship between three TTL files and specification is not clear.
... Diagram is written manually, right?
... and all the tables are automatically generated.
... mismatch can happen, right?

Victor: They are different representation of shapes.

Kaz: TTL and diagram can possibly have mismatch.

<kaz> Kaz: for example, there is mismatch between (1) the resource (=TTL files) and (2) the derived results (=Figure 1, 2 and 3; and description at section 5.2, 5.3 and 5.4) on the TD draft

<kaz> td.ttl => "Figure 1 TD core model" and "5.2 Core Vocabulary Definition"

<kaz> json-schema.ttl => "Figure 2 TD data schema model" and "5.3 Data Schema Vocabulary Definition"

<kaz> security.ttl => "Figure 3 TD security model" and "5.4 Security Vocabulary Definition"

Victor: diagram ideally should be generated from TTL files.
... each module has W3C URL, and accessing the URL gives you rendering of the model.

Kaz: specification and data also should belong to json-schema.ttl
... see section 5.3

<inserted> Description at section 5.3
[[
The class DataSchema has the following subclasses:
* Specification
* Data
]]

scribenick: kaz

Victor: ah, that is a bug...

Kaz: ok
... so the diagrams (Figure 1, 2, 3) are correct and the descriptions at Section 5.2, 5.3, 5.4 should be updated. Right?

Victor: yes

Kaz: in that case, please skim the TD draft (section 5.2, 5.3 and 5.4) again and make sure there is no mismatch between the description and the Turtle files

scribenick: taki

Victor is creating an TD issue...

Issue# 186

<kaz> issue 186

Koster: we can continue to review on this in next call, and semantic API, etc. two weeks from today.
... I will fill in for Darko.

<kaz> [adjourned]