Meeting minutes
agenda
Sebastian: we have some topics about the publication plans
… then a proposal for changing the review process
… we should look to terms/assertions that may be moved from/to Arch
… finally PRs and eventually Issues
… aob?
previous minutes
<kaz> Nov-17
Sebastian: we looked to some PRs
… OAuth PR was not correct
McCool: yeah I had a couple of concerns I commented on the PR it self
Sebastian: minor typo suptopic -> subtopic
Sebastian: PR 1282 was controversial, it is still to be merged
… we have already a list of changes in the TD document
… together with a list of changes in the test report
… webhook pr was blocked by concerns about UriTemplates usage
… we discussed about v1.1 version
… it should be solved now
… minutes ok?
… ok, please publish the minutes
publication plans
Sebastian: we have a good status of the document
… the features list of 1.1 is good
… I would publish a new WD for December
… we can receive feedback
issue 1276
Sebastian: we reached a good consensus for the namespace
Kaz: I suggest to contact Philippe and Ralph
Sebastian: will do
normative sections
Sebastian: kaz requested a list of normative/non-normative sections
… we should follow what we had for 1.0
… and add the new Thing Model section
Sebastian: terminology section is not normative, weird
… is it the same for architecture?
Kaz: I would like to understand the dependencies between the TD spec and the other specs, e.g., the terminology section of TD and Arch
… we also have to mark at risk features
Sebastian: we can only understand at resk features in a test-fest
Kaz: yes, but they need to be included in the "Status of This Document" section when we publish the CR
Sebastian: ok, continuing on counting normative/non-normative sections
… about namespace, do we need to update all the ontology file namespaces?
… we need to understand the best practices
… schema.org for example do not update the namespace
Koster: the URI shouldn't change
… context should be updated
Sebastian: I have the same feeling
… it seems that also saref don't change
Koster: actually it changed
… but because the requirements changed
Sebastian: om too does not have version information
Cristiano: are we talking about ontology namespaces? but no @context
Sebastian: yes about ontology namespaces
Cristiano: ok so the context file is served from another url
Sebastian: yes
Sebastian: maybe it would be better to have a namespace without the year
<kaz> SSN ontology
<kaz> DCAT ontology
Sebastian: we could define a new generic namespace that redirects back to the old URL
Kaz: please have a look to SSN ontology and DCAT ontology for guidance
Sebastian: dcat is using a generic namespace
Kaz: it has it's own namespace
Kaz: also other working groups are having the same problems. anyway, we need to think about what would be the best based on implementers' feedback as well.
Sebastian: yeah for example json-ld 1.0
Sebastian: IMO I would prefer to have a namespace without the year
Daniel: my expectations are that if the content change we should update the Namespace
… updating it under the hood may cause problems
Cristiano: +1
Sebastian: agree but it seems that ontologies work differently
… if you just extend the old one it make sense
mjk: it is language that it has been defined
… not standard knowledge
… so it might be ok to use a versioning approach
Cristiano: I agree
Sebastian: ok let's keep an eye on this
Sebastian: in February we going to have a new test-fest, we can mark at risk features there
… we have one critical section: Canonicalization
McCool: it was meant for signing, but now signing is deferred
… standardizing it now might cause compatibility problems later on. Plus we might leverage on JSON-LD canonicalization.
… ok for removing the section and then profile will take it
Lagally: we can have this defined in the arch
McCool: the problem is that we can't well define canonicalization now, at least in a way that works with signing
… we can pick the datetime format for example
… but other points will just create a very verbose TD
… I would be ok to be used for signing but not for storing
… plus I would remove it from the terminology section
… we can always recover it from the TD 2.0
McCool: json-ld will help us taking our requirements when defining their own canonicalization process
… I would keep 1 2 3 4 steps of the canonicalization process
… 5 is interesting, ontology extensions are tricky to handle
Lagally: we should move this to Profile discussion
McCool: yeah
Daniel: I did work to implement it
… verbosity is not a problem
… to me we can leave it here (no move to profile)
McCool: verbosity is not a problem in signing
Sebastian: ok canonicalization will be removed
… then we have the TM section I would put it as normative
… unless we have problems implementing it
… maybe in the next charter we can have this content in another document
… all the other chapter are identical
Async review process
Sebastian: ben created a formal description of the process
… so that we can move forward faster
… I agree with the point that we should be faster on trivial points
… like on bug fixes/ typos
… any comments?
+1: )
Kaz: we should not rush into the decision, the process must be well defined
Sebastian: currently there're no rules written down
… we need to focus on core features
Kaz: for the record I'm not objecting to the idea itself
Sebastian: we can try
architecture
<kaz> wot-architecture issues with the label of "publication-2.0"
Sebastian: on the issue list you can see grey highlighted terms
… those are assertions that can be moved to the TD
McCool: I have an example of a read-only property: device that can configured with credentials (of course you can't re-read them once you wrote onto the device)
Sebastian: oddly enough all the assertions comes from Zoltan, maybe we can ask him for feedback
McCool: we need to select the ones that should stay on the arch
Sebastian: I agree
Sebastian: arch-op-wellknow-compare should be removed, we have strictly defined vocabulary terms.
… I want to focus on arch-uri-scheme
… we have a section describing concepts similar to the assertion
… we can integrate those
… my main concern is that we should keep it as a SHOULD and not as MUST
… not a lot of IoT protocol has URI scheme
McCool: we need an URI scheme
Sebastian: I would move this assertion to TD
… I'd vote for remove the others
McCool: arch-id-correlations it is intersting
… it is incomplete
… we have multiple TDs for the same thing
… we can't use the same id in different TDs cause dbs will be confused
… we can resolve it with a master TD
… I would move this assertion in the TD spec and clarify better how ID should be structured
Sebastian: I agree, there's always some confusion with the id terms
… is it the ID of the phisical Thing or Thing Description document
… ontology side it is the id of the document
Victor: how you draw this conclusion
… there were guidelines
about to identify physicals objects and web documents
… the spec actually says this
… the id IS the id of the Thing (physical object)
McCool: however we have problems in with Sparql
Victor: not convinced, why ?
McCool: for sure this should be tackled here, the td spec not arch
<kaz> Thing Description ED - 5.3.1.1 Thing
McCool: we can discuss more in a issue
<McCool> https://
McCool: type is optional but we can't use it for framing in TDD
Victor: we can state that something is a Thing and a TD together
McCool: @id == id is problematic
Victor: why should we change it?
McCool: db use @id as key
Victor: I also developed a TDD document ids are generated on the fly
Sebastian: I think we should clarify this soon
Victor: I had no problem with rdf dbs when store tds
McCool: no push back for local ids
<victor> (sorry for hijacking the discussion)
Cristiano: maybe we can explain better that we are defining just a model and the td is a serialization of it
Jan: we can have a dedicated device id
McCool: it has compatibility problems
… bit what happens when it is not defined?
McCool: let's move to discovery
Kaz: we probably need Michael Lagally on this topic Lagally mentioned he would be able to join the Discovery call on Monday if there is any specific topic on the agenda which requires his participation.
PRs
PR 1289
<kaz> PR 1289 - Add 'instantiation' property to security scheme
Victor: I changed only the RDF ontology, but it changes the context
… it is just bug fixing
… triples were missing
Sebastian: minor issue
… I would merge this and later fix the issue
Victor: I would wait the fix before mergining
Sebastian: ok
… is 937 still relevant
… ?
Victor: we can close, the bug was a feature
1264
<kaz> PR 1264 - Fix 948
Sebastian: what's the point
McCool: we don't need an example about device and code
… td 1.0 had implicit and password flows
… we need to re-introduce them
… we should put an assertion saying they are not recommended
Cristiano: how should we resolve this PR?
McCool: I'm more concerned about backward compatibility problems
… we should fix it before continuing
Cristiano: problem with client is that you can't use it on browsers
McCool: let's discuss this in the sec call on monday
1279
<kaz> PR 1279 - print *all* code parts on print
Daniel: should be ready
Sebastian: a small change in the css to make examples printable
… merging any objections?
… merged
1284
<kaz> PR 1284 - add a note about observe behavior
Sebastian: is an improvement of observeproperty behavior
… ok to merge?
… merged
… this a good example of a PR to be merged offline
1292
<kaz> PR 1292 - fix default table entry for observable
Sebastian: an entry was missing
… strange ordering
… merging?
… merged
<kaz> [adjourned]