Meeting minutes
Agenda
Kaz: suggest we concentrate on the versioning discussion given both the Discovery TF participants and the Scripting API TF participants are here to discuss that today specifically.
Minutes Review
<Ege> Jan-18
Ege: minutes are approved
Binding Templates
Merged editorial PRs
Ege: there has not been a PR
Registry
Ege: is drafting a PR about the use case, story and requirements for registries
<Ege> https://
Ege: The use case for having a registry
… based on the charter description, Ege added a potential and a draft of a user story and use case
… also Ege defined a set of requirements, inspired from Jan's analysis
<kaz> i/minutes are/scribenick: mahda-noura/
McCool: bindings as being mandatory, how to deal with that
Ege: it is same for TD, if you have a TD binding you don't have to implement a binding, but profiles are not like that
Kaz: I would like to expect you Ege to add some description and story about why we need to define registry seperately from the specification
Ege: for me the only way would be to publish a working group note
Kaz: I am not objecting at all, just wanted to confirm we're planning to describe the rationale and the need later.
Ege: each requirement will result in rules for the registry
… I think the first requirement is important, a binding should be written by people or organization that are not WG members
… the other part is about associating to a TD binding, the association has to be done by the TD task force
… we should have rules how the process is happening, and should outlive the WG
… the next point is about us managing it, we should make sure there are no two bindings for the same protocol
… if it should to a protocol should map to at least one WoT operation
… the last point is that it the serialization format should be described
Ege: any questions about this?
(none)
Ege: I will proceed with the last part, which are the rules of a registry
<kaz> i/minutes are app/scribenick: mahda-noura/
Koster: this is a great start, the word we want to use is deprecation, a typo in the document
… we maybe want to extend the user story to motivate it, but I think it's a great start
Ege: I can extend the overall motivation section
… merged this PR
Koster: are we going to add the registry in the use case agenda for that TF, do we need to involve the use case TF more? This is some actual content we could start working on
Kaz: regarding the use case, we should clarify what level of use case discussion should be done and where
TD
Versioning Resources
<kaz> wot Issue 1166 - [Policy Proposal] Versioning Resources (McCool's proposal)
McCool: I have read the current documents and would like to summarize my recent thoughts
… we need to distinguish the beta versions
<cris_> +1
McCool: we need to also version all resources, like validations, etc.,
… to make things easy we should map our directories to the url structure
… the final issue is synonyms or generic versions, only to have have version URL's to make our lives easier
… we should make all URL's versioned
Ege: one point regarding matching versions, something that is a breaking change in the schema may not be a breaking change in the ontology
McCool: we can version each file, and then figure out which version would go together
… we can use version directories and version sets
Ege: could you explain that
McCool: github is smart in linking things together and mainting things and on the downside caching is inefficient
… I don't know whether there is a solution for this downside, but I think everything else gets complicated
… we should think of some way that redirection can be used to point to an older version, I think the directory gets versions instead of the single files
McCool: we need to look into some semantic best practices for versioning
Kaz: I've started to think we need to clarify our requirements for versioning based on some concrete user scenario. For example, we need to define what we mean by "Semantic Versioning", and then could think about the details on how to fulfill the requirements.
McCool: we should write a user story
Kaz: we should once suspend this level of detailed technical proposals, and should think about our requirements based on some concrete user scenario. For example, we can start that discussion right away during this call now, but should clarify our approach first
McCool: the main reason why I am concerned with versioning is not to break the systems of current users
Mahda: besides showing the diff, we need to also communicate the change and why the change was made and communicate it to the users
… also what is considered a minor change, and minor or a patch changes
McCool: we have a change log in the discovery
Cristiano: about the changelog, the change could be automatically generated and I guess we can leverage on that
Cristiano: there are developers who try out the specs so there is no version just for us
<McCool> +1 on using github to automate things, e.g. changelogs
Cristiano: we have to derive some guidelines
McCool: I think we should see if we can leverage git to do this for us, can we use tags to generate the URL
Koster: maybe we should use a docstring app in some of the commit messages to generate the changelog
<McCool> re rendering changelog: see w3c/
Kaz: today's discussion is very useful, we have been getting nice and useful opinions, however we should consolidate our need in a seperate document for this issue
Ege: I would make one, totally agree
… there are options other than manually updating specific files and redirections
Ege: I would not create a policy for now, we need more investigation
Ege: do you want to do this discussion in the TD call?
McCool: We could do this again on Thursday, I won't be available on the TD slot, we should try adding comments offline
<McCool> https://
<McCool> PROV is one possible approach to versioning RDF, but may be overkill for us - we generally need to do more research here
Use Case Discussion
Ege: the whole idea is to find promising use cases from issues
… we want to label the issues with a label "needs use case"
… the second part is we evaluate them in respect to the charter
… priority is on business use cases and not theoretical ones
… there can be other task forces, we need to label them correctly
… we can add a "relevance unclear" label if we are not unsure about the relevance for the charter
… we have currently 268 issues and splitting it to the members
… we can take a snapshot of a page in a point in time
Ege: any comments, or whether if someone cannot do this work?
Kaz: I don't disagree with this procedure, but I just want to suggest that we should work with the use case TF and which part of this long work should be handelled by us and which ones by the use case TF
Ege: once we are done with this, the use case TF will start
Kaz: what kind of templates are going to be tranferred to this TF
Ege: once we have the labels, the next task would be to use the template
<cris_> +1
Ege: if nobody is objecting this, I can send a bunch of emails, is this fine for everyone?
<mahda-noura> +1
<McCool> ntd - ttyl
Kaz: once the use cases TF procedure also clarified at some point, this proedure can also be updated based on their feedback
Ege: right
Ege: does anybody prefer TD issues or binding issues?
Cristiano: I do not mind
<kaz> [adjourned]