<inserted> scribenick: taki
<inserted> Matthias: Are there any conflict for June 30- July 5?
<kaz> (no objections)
<inserted> Matthias: Good.
RESOLUTION: the next F2F will be held in Korea on June 30-July 5 (June 30-July 1 for PlugFest)
McCool: Let's plan for next PlugFest.
... In the afternoon, discuss security metadata.
... Outline. What we tried. What's issue...
... Intel: Two exposed Things.
... local https. Basic auth.
... Not used by anyone else.
... using metadata proposals.
... Siemens. Https + basic auth.
Mattias: and bearer tokens
Matthias: proxy support. forward
proxy.
... and reverse proxies. (things only reachable through
proxies)
... used oracle instance.
... disabled cert check using config flag.
... last plugfest, used bearer tokens with Fujitsu beacon
light.
Soumya: I used https. TD was
encypted.
... It was a plain encryption.
... securoty of Thing itself is under development.
Yamada: Https + bearer token (jwt)
Kawaguchi: Global endpoint.
... Let's encrypt. local http only.
Matsukura: Fujitsu used
https.
... proxy supported https.
... locally http only.
... https supported locally, but turned off for plugfest.
McCool: I will put this up to
Github. people can edit it later.
... and I will create a survey.
McCool recaps what we did in Plugfest...
McCool: Issues such as protocol
error. Probably due to firewall etc.
... Worked in hotel but not at Oracle.
... network disconnection. self-signed certification. those
were also issues.
Kajiwara: we try to enable local
device. using local CA.
... It is a CG work.
... HTTPS Local CG.
McCool: only limited set of
authentication schemes. Only basic auth and beaerer tokens
(jwt).
... Incomplete metadata. Those were issues.
Kawaguchi: cross-site scripting
issue.
... Browser prevented us from using cross-site scripting.
Matthias: Was that your own servient?
Kawaguchi: We allowed it. Proxies
did not.
... I used Chrome.
... I had problem when I used TD.
... Advanced ACE.
... Node-Red did not have problem.
Matthias: Chrome behaved
correctly.
... Copper under firefox was not working.
McCool: I also used curl.
Matthias: Scripting issue. therw was not an issue in fetching.
McCool is creating a slide on scripting API issues...
<kaz> -> McCool's slides tbd@@@
McCool: cross-site scripting
issue specific to using WoT scripting API inside browser.
... "Dashboard" app trying to connect to Things that was at
different location.
... any other issues?
Zoltan: ACL is implemented. Need to do provision manually.
McCool: Next plugfest plan. what
do we wanna do?
... security metadata.
Matthias: 30 June and 1 July.
McCool: We need to be done by 1
June.
... We need to create a consistent security metadata set.
... by then.
... we need to try more authentication strategies.
... OAuth2, wider use of bearer tokens.
Matthias: Pop tokens (at least as a 1-1 prototype)
Elena: API keys
McCool: Basic auth
Barry: digest and basic auth.
what's different?
... digest and local authentication should be used
together.
McCool: OCF is based on
ACE.
... metadata for ACE, and OCF. entry points, roles, etc.
... we also should try non-OCF implementation as well.
Matthias: I have implemetation in
node.wot.
... It is work in progress.
... coap implentation in node is fragmented.
<ryo-k> fyi: web page for httpslocal cg is here https://www.w3.org/community/httpslocal/
McCool: First we define metadata, then need to implement.
Matthias: Can you share OCF ACE information?
McCool: authentication server, certification server. ACL.
Matthias: OCF tends to depend on IETF standards.
McCool: Discussion in IETF T2TRG is necessary.
Ari: Lightweight M2M.
McCool: We are gonna have
lifecycle discussion.
... we have lifecycle diagram.
... it has implication on security.
... we have been focusing on operation phase.
Kajimoto: we need to analyze the gap between security document and the issues we now have.
McCool: we still need to do
general discussion.
... Testing validation strategy is related too.
Kaz: We need to clarify requirements before analyzing the gap.
McCool: general discussion first,
then concrete discussion.
... for now, practice first, then generalize.
McCool presenting on Security metadata proposal...
McCool: Issues with current
assumptions, goals and requirements. We need disucission.
... I present strawman proposal
... I generated concrete examples.
... issues.
... different authorization schemes in one Thing.
... different entry points, roles, management styles. etc
... RAML, OpenAPI have this. different authorization scheme in
one thing.
... I made those assumptions.
... We need to discuss whether or not this is a
requirement.
... security interaction patters
Matthias: TD says how to get authorization. role is in token.
McCool: I try to describe
existing mechanism.
... We can validate assumptions llater.
... OpenAPI supports multiple strategies, multiple entry
points.
... we do not want to replicate configuration definition.
... we give a name. and use it elsewhere.
... we can share configuration between interactions.
<kaz> security pullrequest 86
McCool: AND-OR combination scheme.
Elena: we need use cases.
Matthias: When proxy is there, we do not see OCF device behind it.
Elena: OCF is in local network, and has its own authentization mechansm.
Matthias: one thing, how can it possible to support multiple security systems?
McCool: coap and https.
... OCF device with coaps and https.
... We can use OR operation.
McCool showing examples...
McCool: Security is an
array.
... each has @id and "scheme"
... each interaction has "security" field referencing id such
as "ocf-config".
... Proxies.
... proxy configuration and endpoint configuration. we can
define both in "security".
... OAuth is a bit complicated.
McCool showing OAuth metadata definition...
Matthias: we need to check what we really need.
McCool: We should not repeat
information here if it is processed somewhere else.
... i tried to make metadata definition consistent with
existing system such as OpenAPI.
... I will keep updating the proposal.
... There are open issues. compatibility with JSON-LD.
... list of supported security mechanisms. what's in and what's
out.
... validation issues. combination of parameters.
... there can be invalid combinations.
<kaz> security metadata document
<inserted> Kaz: wondering about the proxy/gateway use cases. Do we want to think about server capability within TD as well?
Matthias: We need to be careful what we define for gateway use cases.
McCool: we first should focus on what we need.
McCool is showing detailed specification section...
McCool showing various examples...
McCool: presentation is just a
summary.
... for now 5 schemes are listed.
... each scheme can specify relevant protocols.
... API key is a blob. Bearer tokens have structure.
... OpenID and inter-ledger are interesting.
... Please take a look at the proposal document, and provide
comments.
... I created issues in Github.
... for open issues.
... such as versions for security schemes.
Kaz: Do we really want to use "OCF Security Model" as a categor?
McCool: it is scheme="ocf"
... It is work in progress.
Kaz: given other entry names are technology-based, maybe "ACL-based security" or "SDO-specific security" which includes this (=OCF Security Model) as an example
Sebastian: should we keep discussion separate from TD vocabulary discussion?
McCool: whether common or specific to schemes. It depends on this.
Matthias: extension points need to be defined in TD.
Sebastian: common part needs to be discussed in TD call.
Matthias: binding should be discussed in security call.
Dave: abstract model can be
discussed in TD.
... we need a framework around TD.
<kaz> [break until 11:15am]
<ege> scribenick: ege
<inserted> -> @@@tbd Slides
Kawaguchi-san: this presentaiton
will be about presenting examples of interaction sequences, not
a new standard
... no clear description of end to end sequence and
inconsistency among spec drafts, e.g., WoT Architecture, WoT
Thing Description and WoT Scripting API
... I only have HTTP prepared so my example will be based on
that.
... Describing an example of HTTP get request with scripting
api (sending the request, getting a promise as a
response)
... Similar example description with an HTTP PUT request
... Now some new stuff, especially for the plug fest: HTTP long
polling
... Sending a get request and getting the answer once the
server device detects a change and sensds a response
McCool: question on long polling
Matthias: What you asked is more about multi-XXXX and not actually long polling
McCool: ok. (to kawaguchi-san) what is a change , what is a previous state. What happens if you have a request during a change
Matthias: That would be more like a bad implementation
McCool: I would think of getting a previous state in order to understand if there is actually a change
Matthias: what is the actual problem
McCool: What if I have the value 0, it changes to 2, there I subscribe and then it changes to 1 and I get that value so I miss the change to 2
Matthias: If you implement it right there shouldnt be such problems
Zoltan: We are not interested in making precise time stamping problems etc.
Matthias: There is a way by using
cookies. First get you store a cookie as a server and the
second time it gets a GET request it blocks it
... I wanted to the client side of long polling in node-wot for
long polling during the plugfest but didnt have time
McCool: I wanted to implement both server and client side with node wot (SAID BEFORE THE 11:37 Matthias)
Matthias: There is also another pattern where even if you dont have a change you send something saying that hey Im still here
Koster: We can all agree that observable properties is event type
Ari: http, using different resources
Matthias: If a device is already existing, you cannot impose to put a timestamp
Zoltan: what about putting timestamps in responses
switch the order of 11:42 and 11:43
Zoltan: but the scripting should expect behaviour
Matthias: CoAP has the observe clock
Kawaguchi-san: Now simple web
socket that has been implemented by Siemens
... presented the slide
Matthias: this is simple
websocket so you need to define the underlying protocols
afterwards
... (After a question of McCool) we cannot think what is the
application use case
Dave: What about if I want to send 10000 property update a second
Matthias: Then you should events
McCool: My thinking is that simple things should be simple
Dave: yes but complex things should not be impossible
Matthias: but you can already do that
Zoltan: (explained how you can do it)
<ryo-k> Series Transfer Pattern: https://tools.ietf.org/html/draft-bormann-t2trg-stp-00
Koster: There is an IETF draft by bormann that can help about it
Kaz: What is the difference between slide 4 and 5 from the slide design point of view? the difference between the possible event handling mechanisms (and important points) should be described in addition to the diagrams themselves
Kawaguchi-san: I have found this action pattern and I have found this invokeAction method
McCool: return codes of actions
Matthias: there is no current XXX about having Hypermedia control kind of stuff
Zoltan_and_Matthias: It should be such that you get status or TD or whatever and from the information you learn what you can do with it
McCool: Scripting API should be protocol independent
Matthias: It might be good to
have something in the TD that says that I will do this
action
... Then it proceeds on doing the action. In the meantime you
can still access the server. In the example of a cleaner, the
action could take 2 hours and then respond and all this time is
sort of not used.
... you cannot have two different implementation of a request.
You cannot have one where it tell you that it will do the
action rightaway and another that starts doing the action and
then responds. It is possible but way simpler to pick one
McCool: (before Matthias' answer he asked something about having two version described in the TD)
Matthias and Sebastian: (in response the Koster's question) this type of flow should make it easier to people to understand the difference of action and properties
Kawaguchi-san: Now event
patterns
... There is a github issue on how to use property action
event
McCool: We need to see how MQTT works, maybe Michael has something to do with that
Sebastian: I would like to see
CoAP in the observe patterns
... I have a student working on MQTT for Web of Things, I can
provide input later on about it
Kawaguchi-san: This is mostly to illustrate and to say that everyone is ok with the action patterns
Matthias: we dont do discussions on "architecture", we do specific topics, e.g. terminology is a part of architecture
Matsukura-san: (a question on what about proxies that we have introduced in plugfests)
Kawaguchi-san: I think we should do another slide where we merge proxy and basic intereactions
RESOLUTION: both Panasonic diagram on the basic interaction and Fujitsu diagram including proxies can be included as part of the appendix (after some cleaning-up)
[break until 11:15am]
Matthias: Presenting property definition in the terminology. it is updated
Dave: What about the observable aspects, is it described somewhere
Ari: What about write only
Matthias: That would be modeled by actions
Barry: What if someone cant read it because of access rights
Matthias: That would come from the orthogonal security aspects, it shouldnt be mixed with property deifinition
Taki-san: What about previous states
Matthias: You can have it in the
application layer and model it by an array
... I understand this might be needed, can you bring a use case
to discuss
McCool: Or an action to get the history
Barry: or use blockchain!
Matthias: (After a question from Lagally) If you want to model something, start with property, if you cant model pass to action, if you cant model it, pass to events and only after that if you cannot model it then we can talk about having a 4th interaction pattern
McCool: What about state transitions ( EGE: didnt get the discussion about the state machine etc.)
<kaz> Kaz: wondering if all the "properties" (or rather members/fields of TD) need to be exposed, or only exposed ones are called "properties"
Dave: What about generating events in the client
McCool: You can do it with actions
Dave: yeah that is a workaround but what about the concept
McCool: an action with semantics
Dave: No that is a workaround. What if there is a usecase that we dont know that can be modeled only with a client raising an event. I am not saying that there is one and that we should add something but more like raising the a question
Matthias: You want a P2P network
that you can do with things being servient
... the initial definition of action had the idea of doing a
physical change
McCool: Maybe actions should be not only about internal state because maybe i dont care about the change of the internal state but the result of the action that is something about the physical world
Milan: I dont think you should call strong consistency in the event delivery. You should either say best effort or guaranteed delivery. Strong consistency is a bit ambigous
Public: people agree on what Milan says
Matthias: So what are the use cases of read only, writable and observable properties
<kaz> [lunch till 2pm]
Matthias: I didnt have time to explain the updates
<kaz> scribenick: kaz
<inserted> -> Victor's slides@@@
Victor: new features from JSON-LD
1.1
... for the sake of the following discussion by Sebastian and
Matthias
... syntax, etc.
... [Objective]
... define the transformation
... to RDF
... using only standardized procedure
... 3 possible steps
... set WoT context if not present
... default values
... transformation to RDF
... [changes]
... default values
... getting rid of arrays
... couple of other changes
... key-indexed interactions
... JSON Schema syntax for Data Schema objects
... relax of the constraint on arrays
... for @context and @type
... for easier implementations
... [Default values]
... [Key-indexed interactions]
... we use "name" to identify interactions
Matthias: what does "framing" mean?
Victor: several possible
representations
... compact one, nested one, etc.
... all the formats are expected to be equivalent
... based on the same RDF model
... TD is normalized format we're looking for
... framing algorithm for defaults
... second thing is key
... representing interaction
... where the key is the identifier
McCool: link to other places?
Victor: "name" here is not equivalent
with the one from RDF
... still some open issues
... provided use cases
Soumya: app servient wants to parse it?
Victor: easier for an object to use arrays...
Matthias: parsing problem and accessing
information
... software object identical with TD structure
... codes are iterating
Victor: this is what our JSON Schema
is defined
... open api also uses that
... [JSON Schema syntax]
... "fields" before "name" and "schema"
McCool: "prop" could be name of some property
Taki: @@@ prohibited?
Victor: reusing JSON Schema
... properties come from TD properties
... separate question
... another proposal for that
Matthias: let's focus on what JSON-LD 1.1 is like
Dan: W3C itself should make decision which to use
Matthias: if we go down to the path
(1.1), what is the requirements?
... complexity?
... key is nice applicable feature
... AC review for the proposed Charter
... JSON Schema is independent from JSON-LD
McCool: what are our use cases?
Victor: framing is the most important
feature
... there is no easy way without that
... on the other hand, many people have started to use JSON-LD
and found problems
Matthias: regarding dependency
... syntax and semantics
... discussion during TPAC2017
... adapt to new concept
... being clearer
Sebastian: like the change (e.g.,
framing)
... interested people could provide use cases
Matthias: we should go through the changes
Victor: [COnstraint on arrays]
<danbri> JSON-LD charter is before W3C AC for review (https://lists.w3.org/Archives/Member/w3c-ac-members/2018JanMar/0054.html - member only link). Draft charter is (public link), https://www.w3.org/2018/03/jsonld-wg-charter.html
Kaz: left side and right side?
Victor: possible usage here (not left as 1.0 and right as 1.1 here]
Matthias: TD directory should support
this
... how to deal with this convention?
Zoltan: array for "@type"?
Matthias: you can do that
... the parser would handle it
Victor: if you use other JSON-LD convention, other could have string, etc.
McCool: restriction for small devices?
Matthias: kind of education
needed
... could be an array
Victor: [Issues]
... a couple of issues
... identification
... WoT convention, JSON path, RDF normalization
... Base URI
... use of JSON-LD's "@base"
... use of TD identifier
... [Identification issue]
... in both JSON-LD and JSON Schema
... there are properties and actions
... using "id" is JSON-LD 1.1 convention
... having "uuid" for some id
... if there are 2 identifications, would have id conflicts
McCool: observe tag?
Victor: "id" is yet another URI
McCool: relative to where the TD
is
... may or may not be same
Victor: possibly other kind of
IDs
... #properties/example/schema/properties/id JSON Path
... not sure how they handle it
... this is not part of the JSON-LD spec itself
... 3rd alternative: hash://md5/9f86d081884c7d659a2feaa0 RDF
normalization (randomly generated)
... common with temperature, etc.
Kaz: who handles the hash
ID?
... possibly TD directory?
Victor: possible option
... also every agent may also expose the ID
Barry: new hash schema?
Victor: took from some proposal
... there are different ways there
Barry: talk about that later
Dan: RDF hash would make
sense
... ":hash"
Barry: talk about later
Victor: [Base URI issue]
... how to declare TD
... how JSON-LD is defined here
<danbri> discussion of http://json-ld.github.io/normalization/spec/
Victor: just add "@base":
"urn:wot:myThing"
... we could specify within the TD spec
... only has the space as the key
... in this case
... urn:wot:myThing/example WoT convention
... this is something we use
... might need access control
... submitted to the JSON-LD CG
... but pushed back
Matthias: why out of scope?
Victor: require some
preprocessing
... we could continue to use option with JSON-LD 1.0
Matthias: discussion on the
pre-processing stage?
... could also take the base id to fill the content
Victor: possible solution
Matthias: nice solution is
... this is TD-specific
Victor: this "@base"
"urn:wot:myThing" would be put on the array if used for
TD
... wanted to show this diagram...
McCool: we actually see them?
... or transformed results?
Victor: put into the TD as soon as the property is processed
McCool: how would a big ugly hash work?
Matthias: if you input extra document
which is located somewhere
... you don't need the hash itself
McCool: possible human-readable
id?
... in a form
... as alias
Kaz: possibly additional "display name" or "exposed name"?
McCool: within the document for the
developer, the id should have a human-readable alias
... most users don't handle that
Victor: could be possible
... [diagram of DataSchema]
-> @@@url of Victor's DataSchema diagram tbd
Dave: extended diagram for
DataSchema?
... used for multiple times?
... we can make it easy to use that so
Victor: all the data included in the DataSchema
Matthias: it's possible
Victor: we can reuse it once it's defined as part of DataSchema
Matthias: those are small
extensions
... basic building blocks
McCool: some use case on binary
data
... extend the Schema for that?
... media-type knows about that
Victor: anyway requires container
McCool: what if it's empty?
... leave it out?
Kaz: clarification on the colors
Victor: yellow upper nodes are JSON
Schema
... green lower nodes are TD extensions
... [another diagram on SenML]
... binding templates spec
... interaction for properties here
... (goes through the diagram)
... abstract model regardless of the serialization
Sebastian: comment on the current TD ant
this model
... for the future
Ari: just a future example?
Victor: yes
... [yet another example]
... provided by Matthias
... battery->schema->0.0.100.0
... we can input this into the doc
... I'm done
McCool: min/max?
Victor: wanted to explain that kind of detailed but couldn't due to network connection
Matthias: "rssi" property
Victor: (shows the TD draft)
... (rawgit version)
Matthias: (explains the example)
... example 2
Zoltan: multiple ranges?
Matthias: whatever complex types
... might want to talk with the JSON Schema guys
Dave: arrays in JS 1.1
... order or unorder
... maybe unordered one would be less costly
Victor: JSON-LD?
... already covered
McCool: 1.0 as well?
Victor: yes
... just RDF list is used regardless of whether ordered or
not
Matthias: what JSON-LD 1.1 could bring
to us?
... is this something we want?
... should follow 1.1 version?
... note that we could be delayed by using 1.1 version
... this could be raised within the AC Review for the proposed
JSON-LD 1.1 WG
Dave: would be good to join that group as well
Matthias: will look into this
Dan: some awkward characteristics
on JSON-LD
... you need @context
... a bit awkward
... not sure this group really should add anything to their
work
Victor: this work should be standardized
McCool: 2 comments
... our schemes fixed??
... any applications
... larger scope for IoT
Dan: when the RDF model group had
discussion
... still questionable for this group
Lagally: when the draft would be
published?
... we want to wait until JSON-LD 1.1 becoming a REC?
Matthias: no
... the roadmap I imagine
... 1.1 version is based on what they have been working
... may start around June
... figure out what the features to be fixed
... still loose end
... we have initial strawman for the next f2f if we start our
work for 1.1 now
Lagally: wondering about the risks
Matthias: it's a complicated
situation
... my expectation is JSON-LD 1.1 based version (of WoT specs)
could be stable
Lagally: wondering about actual product implementations...
Sebastian: wouldn't expect yet another big changes...
Lagally: should work with the stable version?
Matthias: you can new features if you
want
... same mediatype definition anyway
McCool: various possible issues
... if early enough, we might be able to resolve them
Soumya: hear 2 directions
... wondering about what oneM2M is doing
... they're using 0.a version for standardization
Matthias: the model would not
compatible...
... their style is spec first and then implementations
... on the other hand, we've been working on implementations
simultaneously
... another point is
... the model of TD itself didn't change drastically
... we have property, schema node there
... property could directly have type
Victor: not the way we should use JSON Schema
Matthias: meant small changes about the underlining model
Victor: possible solution might be using RDF itself :)
Matthias: possibly we can use pre-processing
McCool: as our plan b
Lagally: when we could expect
implementations?
... might be going to 2020
... note that I'm talking about device manufacturers
Kaz: wondering if we could think
about the core of JSON-LD vs 1.0 profile and 1.1 profile
... and work on both
... and then once the 1.1 version is fixed mainly work on
that
Matthias: would try a vote
... who would prefer 1.1?
... whould would do that?
McCool: what version would make sense?
Kaz: not the final decision but people's opinions at the moment
Kajimoto: difference between 1.0 and
1.1?
... if the changes are very small, we can assume 1.1
Matthias: the changes are stronger than
the ones they made previously
... positive feedback from Mozilla and EVRYTHNG as well
... would go for one specific solution
Taki: Victor explains the changes
Sebastian: more data side
Matthias: let's see what the JSON-LD 1.1-based TD would be like
-> slides tbd@@@
Sebastian: first change (example 4 from
TD)
... possibly semantics may not be decided
... JSON-LD 1.1 requires @context
... but it should not be necessary
... still based on the RDF model
... concrete triple
... at @context
... we need kind of post-processing as well
Matthias: possibly 3 processings?
Sebastian: we have to integrate the context
Matthias: in that case 3 processes?
McCool: user's perspective
... what 1.0 and 1.1 are like
... side-by-side examples?
Matthias: what about example 1?
<danbri> maybe typo on screen: Propertis (I think, fuzzy eyes :)
McCool: maybe we can generate an example?
Matthias: would like to look for that
(more discussions)
Sebastian: one big change is...
... (going back to the slides)
... [Downside of Current Workin Assumption]
... interaction container
... by the usage of "@type"
... class, type of the interaction model
... we use many "@type"s withing TD
... kind of interaction pattern
... semantic information like "iot:BinarySwitch"
... also we have to use container with JSON-LD 1.0
... because not allowed to use keys
... no restriction for that any more
... mandatory notations like "writeable", "observable"
... mediatype as "application/json" need to be defined
everytime?
Matthias: some more discussion on
"form" vs "link"
... we can ignore if "writeable" or "observable" is False
Sebastian: [Develoer Perspective]
... list of points
... usually HTTP/JSON is used on the Web
... why do I always have to write that down explicitly?
Matthias: may specify the default as HTTP, CBOR, etc.
McCool: mainly use CoAP
... OCF devices are CoAP-based
Matthias: actual commercial deployments use CoAP
McCool: default values always the
same?
... other values could be set?
... from security viewpoint, constant default would make
sense
Sebastian: [JSON-LD 1.1]
... [Pre-processing with JSON-LD 1.1 ...]
... [@context #103]
Matthias: let's take break now
[break until 4:10pm]
<inserted> scribenick: nimura
Sebastian: explaining about TD - W3C editors draft
Example4: Experimental TD example
<inserted> -> TD Example 4 based on JSON-LD 1.0 and 1.1
Matthias shows different
1.0: LD+JSON need @context
1.1: TD+JSON, we can do pre-processing
we still have name fields
ignore semantic markup @JSON-LD1.1@@@
Valid URI/(URN) is used for identify the TD
Sebastian: we already have a years ago the JSON-LD but gone after that
Matthias: property has JSON-LD 1.1 object.
McCool: the property is nice, but action and event are confusing
Matthias: programming language like JS restricts: name is identifier
link was singular but currently plural
we want re-use @id?
an object has single key: @id
"level": "name" work, but ambiguous.
when we starts use schema, this is one of the risk because there's nothing yet.
few solutions there and risk there. 5% of the case?
taki: can we be the pre-processing optional?
that's we are trying to do.
Matthias: we do this changes.
"integer" resolve URI in local, so no collision.
we are going to consistent to JSON schema.
RESOLUTION: we would like to go for the changes based on JSON-LD 1.1
major topic in TD call is explain about the issues at github.
link vs forms: it's like json schema
more natural from scriptingAPI point of view.
issue #88, #108
<inserted> TD issue 88
<inserted> TD issue 108
Protocol binding: for example OCF, non-standard implement implementation
It introduce bit complexly for property, but people continue to implement
Conclusion: exposing web resource, link to web resource is sufficient for get/put, you know what to do.
Property become less powerful but concept becomes simpler.
What happens for observe property?
How to differ get end pint and observe end point?
If you need to read OCF, need to have header.
stick to form there.
link gives relation to resources.
form gives interaction, but that's weird.
forms in html world have specific meaning providing data
Mm: stick to form, not automatically processing
Non standards interaction, we need to cover.
pre-processing has defaults, some kind of suggestion is needed.
"name" term there, @is becomes handle and unique.
human readable expression is favorable that's helps developers
about name, is it optional?
it's still working.
for the reference of object @id is necessary.
that's central of mandatory.
agreed on make "name" optional.
but name always require make sense.
we don'have "name" in some examples.
level can be used for expressing international language definition.
level and name are different.
level does not necessary like name
Name: {"en"]:"My Thing", "de":"Mein Ding"}
do we really needed?
that's internationalizable solution.
descriptions should be optional.
inside description maybe common markup can be defined.
description can be internationalizable.
about tags,
popular model among developers.
We have label, so not necessary tags?
Do not include TD vocabulary to tags.
about version,
is it optional?
it is useful for all of the application.
if we introduce change on TD version, runtime could handle it.
no version for TD, but JSON-LD version?
OCF has spec version.
<victor> candidate terms from standard vocabularies: owl:versionInfo, owl:priorVersion (not ideal), dc:hasVersion, spdx:versionInfo (best)
maybe instance version can be introduced?
thing should work like web. what's the purpose of version?
<kaz> (MLagally shows some examples on Java)
TD must be self contained: fetch all required web resources.
about author,
author=manufacturer
URL+manufacturer
It's not author.
however TD can have author.
minimum thing is support URI for fetching.
about domain,
as seen in iotschema.org
do we want to separate into domain?
In the plugfest, many integrations are provided by companies, so share the info and update the architecture document.
device servients were located in two place.
oracle provides solution in Praque.
proxy servients coordinate application and devices.
these app from Oracle or so could access remote proxy.
role of proxy servient is manage TDs and coordinate connection between apps and devices.
how to use proxy servient?
device connects to local network that connected to local proxy servient.
then app can search the device from TD directory.
in the future, proxy servient supports binding template.
Zoltan: what discovery mechanism is used?
proxy servient contains Thing directory.
Zoltan: only devices underneath can be controllable?
remote proxy that connected multiple local proxy servients handles devices underneaths.
Zoltan: what is the request?
Fujitsu specific approach is taken.
McCool: how do the devices discover?
TD directory is the implementation of core directory.
McCool: what protocol uses, standard way?
victor: look up is different from Siemens one.
McCool: how security handles? how do I translate?
<kaz> Kaz: if needed, we should ask Sano-san from Fujitsu for clarification on detailed protocols for discovery/registration
app never see local address.
security metadata to TDs would be added
Is discovery supported like query?
Still simple approach by search name is taken.
Assumption is names are unique that's not good assumption.
next time Fujitsu might support iotschema approach.
SSE and long polling are supported.
nobody implemented SSE in plugfest, but Fujitsu check that.
compact WoT core is developping, and next time we will show the device.
thing directory, proxy and the variations can be reflected to architecture doc.
<kaz> Kaz: just wanted a clarification
<inserted> ... the first point here (slide 7) means updating the preparation/guideline.md for the next plugfest and the second point means updating the WoT Architecture document, e.g., the Appendix section like the one from Kawaguchi-san
showing scalability experience for example 1 million devices will be useful.
kawa: register things at one time is convenient.
<kaz> [ Day 1 adjourned ]