TD model

topic of the meeting is to get a stable version of Thing Description

starting with a review of the proposed WoT Ontology from Maria Poveda

Danh has a question about identifier scope

terms may map differently depending on the scope of the property

sebastian: the example "name" term has the same meaning regardless of scope

maps to rdf:label in all cases

danh: foaf:name for example has a different meaning in the context of foaf

sebastian: in this case the "name" term would just need to be displayed as a human readable name

darko: nothing stopping us from using different identifier meanings in different context

danh: maybe we should use full names in the TD

sebastian: the goal is to represent the simple minimum information about TD elements, nothing stopping us from adding more

darko: can see how there would be ambiguity
... when we integrate other vocabularies there will be more terms in the document
... may need full names to disambiguate

danh: examples from schema.org, does not reserve a schema.org vocabulary
... every property needs to have a globally unique name

simple term without namespace could be confusing

sebastian: the use of simple names takes advantage of JSON-LD separate context, providing a simple JSON look and feel for developers
... can always use namespaces in JSON-LD if needed
... the idea is to make TD useable without semantic web knowledge, to expose a simple structure for the minimum set of properties
... reference the Current Practice document, where TD vocab is integrated with other ontologies

danh: functional identifiers are more important than textual descriptions
... text descriptors need to be translated to local language, for example
... for example, actuable, writeable
... actuable and writeable are functional identifiers

darko: expecting to discuss keywords like actions but this discussion seems important

sebastian: in the case of "name" in the example, the meaning is the same when used in different classes

darko: we want to make TD machine understandable
... the range for a particular property may be different when used on different classes

danh: validation could depend on a detailed understanding

sebastian: long identifiers can be a problem, as well as the added complexity of more property types

darko: want the core vocabulary to be well defined and not need reasoning

sebastian: name property (rdf:label) does not have range constraints

mkoster: summarized domain-range constraint issue with reusable property types

sebastian: reference to Dave's RDF model which has reusable property types
... recommend aligning the TD models on reusable property names, also baseuri

danh: base should be uri type value, well formed, not plain string
... should use well defined data types from xml schema xsd:

sebastian: references in a TD should be relative to base URI

link seems to be confused with baseuri

danh: need to expose different entry points for different uri schemes, etc

sebastian: entry points should be for either thing or interaction, not both

danh: like a landing page on a website

victor: base and entry point are not the same

mjkoster: the API entry point is TD itself, discovery is done through TD

sebastian: clarify between "link" and "baseuri" in the model from Maria

danh: need a consensus process with clear description of items one by one, to avoid group confusion
... example from SSN extension work to add actuation

sebastian: we need to formalize the model we have now based on the feedback, need to clarify some items and get it stable
... starting the standardization process; there will be less opportunity to change things

danh: what is the process for publishing a working draft?

sebastian: a current release of the TD specification deliverable
... there is continuity from 2 years development in the IG

change "interactionPattern" to "interactions"

sebastian: does it make sense to have no interactions? just hyperlinks

mkoster: use case needs more thought but there could be a TD with only links, pointing to other TD elements or mapped resources

interactions

sebastian: should remove the units definition from the core TD

darko: yes, units are part of a horizontal vocabulary

mkoster: agree

sebastian: input data vs. output data; sebastian took a note

discussion of functional properties and semantic annotation

danh: schema.org contains the knowledge relations, the resources, and TD in our case, will carry annotation from the knowledge graph

is communicationProtocol needed?

darko: need to ask the group if this is useful communication metadata

sebastian: maybe useful for security class information

decision to ask if it is needed and remove if not needed

dataSchema

sebastian: don't need data type here

danh: can this be used to map different schemas, e.g. OCF

sebastian: currently json-schema but want to allow other schema languages
... make a version and submit for incorporation and review on Friday

namespaces

sebastian: is everything defined in one TD namespace?

darko: if we remove the extra stuff e.g. units, it should be only TD terms

kaz: should be able to use the proposed namespace if we provide a descriptive document at the URL

darko: should serve RDF ontology, JSON-LD context, html text according to the request URI parameters

sebastian: www.w3.org/ns/td

<Victor> http://schema.org/ (Accepts:application/ld+json) serves the JSON-LD context

<Victor> http://schema.org/ (Accepts:text/turtle) serves the RDF vocabulary

sebastian: Osaka plugfest schedule may not give us enough time to update TD, target Dusseldorf for the new TD
... thanks and adjourn

<kaz> [ adjourned ]