Meeting minutes
minutes
Lagally: Feb 10 minutes
<kaz> Feb-10
Lagally: anything needs to be changed? Any objections to publish?
… hearing none, will be published.
PRs
PR #695
<kaz> PR 695 - fixes #688: Improving language, adding rfc2119 assertion
Lagally: improving language, rfc2119
<kaz> diff - 7.1.3 Links
Lagally: suggest we use Web Thing consistently for Thing with a network interface
McCool: I would be ok with that, as a more precise subclass of Thing
… in which case Device and Service are subclasses of Web Thing (and also, indirectly, Thing)
Kaz: if we need to discuss the data transfer diagram for this PR, we should rather discuss the terminology issue to clarify the basic components and data transfer among them
McCool: suggest we do the diagram offline, and have a pure class relationships without extra stuff we have to maintain (like descriptions)
Lagally: (edits diagram)
Lagally: ok, need to make some adjustments, will hold on this one for now
PR #696
<kaz> PR 696 - New section on "virtual things", clarifying terminology
<kaz> related Issue 682 - clarify virtual thing
<kaz> diff - 6.9 Virtual Things
McCool: I think "abstract thing" is the wrong name, could be "thing that has metadata", i.e. Metadata Thing
… we do have use cases for some of these, e.g. compositions are already in TD spec, links things (called Thing Links, actually) are in Directories under discovery
Kaz: might be good to have "levels" of definitions
… and then there is virtualization, mapping between physical and virtual entity
McCool: right now virtual thing "represents" other Things, and this is a different kind of relationship than subclass
Kaz: right. if we've not yet clearly defined "virtualization" yet and would use "representing" as the basic relationship, that's ok. however, we should split "representing layer" and "represented layer".
Lagally: seems composition thing is a subclass of link thing
McCool: location thing (thing representing a location) might be very complex
… however, it may simply be an RDF class, e.g. from the BOT ontology
Kaz: location itself is information which can be part of the TD, so I'm not sure about the "location Thing" as part of this diagram. maybe a sensor entity providing location information
Lagally: ok, let's leave location off for now and move
PR #700
<kaz> PR 700 - Update Abstract
McCool: so added "prescriptive when necessary" and took out link to Use Cases (refs not allowed in abstract)
PR #701
<kaz> PR 701 - Update Implementation Report link in SOTD
Lagally: not yet done, let's hold
Kaz: so we'll wait until the actual report is once fixed. right?
McCool: yes
PR #711
<kaz> PR 711 - Definitions for Device, Service, etc.
McCool: definitions for Device, Service, etc. as discussed