See also: IRC log
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
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
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
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
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
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 ]