diff --git a/events/2021.09.Online/RESULTS/Geolocation/README.md b/events/2021.09.Online/RESULTS/Geolocation/README.md index 661506bf..deecf4b2 100644 --- a/events/2021.09.Online/RESULTS/Geolocation/README.md +++ b/events/2021.09.Online/RESULTS/Geolocation/README.md @@ -1,12 +1,23 @@ # Geolocation -Related issue: https://github.com/w3c/wot-testing/issues/167 -## Participants: +## Participants + * McCool - Intel ## Description -Issue description + +* Ontology for embedding geolocation data in TDs and in Thing +* Example TDs and services +* Geolocation filters in SPARQL +* See Intel TDs and Project ## Discussion -Comments from issue +* Need way to distinguish fetching data from a TD itself vs. from an interaction the TD describes +* Problem may also be more general and apply to other kinds of data, e.g. temperature +* May also be other kinds of data that is static vs dynamic, and described by separate thing +* Need to think about JSON pointer syntax related to TD fragment identifier (IANA registered, assuming) + +## Related Documents and Links + +* [WoT Discovery Geolocation](https://github.com/w3c/wot-discovery/blob/main/proposals/geolocation.md) diff --git a/events/2021.09.Online/RESULTS/Hypermedia/README.md b/events/2021.09.Online/RESULTS/Hypermedia/README.md new file mode 100644 index 00000000..e39e5a0b --- /dev/null +++ b/events/2021.09.Online/RESULTS/Hypermedia/README.md @@ -0,0 +1,139 @@ +# Hypermedia protocol proposal 3 + +## Description + +Sorry for posting this late, but I couldn't join the last two days of the PF and I didn't have time to create a proper project description. + +In this plug-fest, I played a little bit with the third proposal of the Hypermedia protocol for actions. I created a [repository](https://github.com/relu91/wot-hypermedia-test) with a bunch of testing scripts that I used to evaluate the idea. + +Here I'm reporting the consumer side because I think it helps to understand the advantages of this new approach. + +### Greenfield + +For new WoT aware ExposedThings the consumer can just assume that action may return an ActionDescription and use it to interact further with the action instance. Notice how no id tracking is need, the code flow is really similar to what the consumer already does for a normal WebThing: + +```js +WoTHelpers.fetch("http://localhost:8080/testingactions").then( async td => { + const thing = await WoT.consume(td); + + if (!td.actions.longRunning || td.actions.longRunning.output.model.href !== "http://localhost:8888/model.tm.json") { + console.log("Long Running action is synchronous"); + await thing.invokeAction("longRunning"); + return; + } + + console.log("Long Running action is asynchronous"); + + const actionInstance = await (await thing.invokeAction("longRunning")).value(); + console.log("Action invoked",actionInstance.id); + + // from here on I can use the action as if it is a webthing + const actionThingHandler = await WoT.consume(actionInstance); + console.log("Monitoring", actionInstance.id); + + const interval = setInterval(async () => { + try { + const status = await (await actionThingHandler.readProperty("status")).value(); + console.log("Status", status); + + if (status.status === "completed" || status.status === "cancelled") { + console.log("Action has stopped:", status.status); + clearInterval(interval); + } + + if(Math.random() < 0.1){ + // cancel with action with 10% probability + console.log("Cancelling action"); + await actionThingHandler.invokeAction("cancel"); + } + + } catch (error) { + console.log("Can't read", error); + } + + }, 1000); + +}).catch(e => { + console.log(e); +}); +``` + +### Brownfield + +For brownfield ExposedThings (i.e., devices that already have their own API and we cannot return an Action Description from an API call). The consumer has to do additional operations to obtain the final ActionDescription but I think it is reasonably easy to then interact with the action instance. +Here's the script: + +```js +const pointer = require('jsonpointer'); + +WoTHelpers.fetch("http://localhost:8080/testingactions").then(async td => { + const thing = await WoT.consume(td); + + if (!td.actions.longRunning || td.actions.longRunning.output.model.href !== "http://localhost:3000/model-brown.tm.json") { + console.log("Long Running action is synchronous"); + await thing.invokeAction("longRunning"); + return; + } + + console.log("Long Running action is asynchronous"); + + if(!td.actions.longRunning.output.model.mappings) { + console.log("Long Running action has not mappings -> is a green field device skipping"); + console.log("See example: consumer.js"); + return; + } + + + const actionInstance = await (await thing.invokeAction("longRunning")).value(); + console.log("Action invoked", actionInstance.id); + + //Create a "Action Description" from actionInstance and tm + const tm = await WoTHelpers.fetch(td.actions.longRunning.output.model.href); + let tmString = JSON.stringify(tm); + + const mappings = td.actions.longRunning.output.model.mappings; + for (const p in td.actions.longRunning.output.model.mappings) { + const variable = mappings[p]; + const value = pointer.get(actionInstance, p); + const exp = new RegExp(`{{${variable}}}`, 'g'); + + tmString = tmString.replace(exp, value); + + } + + const actionDescriptor = JSON.parse(tmString); + // action description contains the TD that can be used to interact with the action + const actionThingHandler = await WoT.consume(actionDescriptor); + + const interval = setInterval(async () => { + try { + const status = await (await actionThingHandler.readProperty("status")).value(); + console.log("Status", status); + + if (status.status === "completed" || status.status === "cancelled") { + console.log("Action has stopped:", status.status); + clearInterval(interval); + } + + if (Math.random() < 0.1) { + // cancel with action with 10% probability + console.log("Cancelling action"); + await actionThingHandler.invokeAction("cancel"); + } + + } catch (error) { + console.log("Can't read", error); + } + + }, 1000); + +}).catch(e => { + console.log(e); +}); +``` + +I want to underline that all of this already works with `node-wot` as it is, no API changes are needed. + +## Participants + +* Cristiano Aguzzi (@relu91) diff --git a/events/2021.09.Online/RESULTS/Node-Red integration (SPARQL query)/README.md b/events/2021.09.Online/RESULTS/Node-Red integration (SPARQL query)/README.md new file mode 100644 index 00000000..094ef8cb --- /dev/null +++ b/events/2021.09.Online/RESULTS/Node-Red integration (SPARQL query)/README.md @@ -0,0 +1,38 @@ +# Node-RED integration (SPARQL query) + +## Description + +* Directory-based discovery (using SPARQL) and auto-population + +## Participants + +* Kunihiko Toumura (@k-toumura) + +## Activities + +* [x] Check availability of Things and Directories +* [x] Create UI for querying Directory from Node-RED +* [x] Test auto-population feature using participating Things + +Current implementation uses following simple SPARQL query: +```sparql +PREFIX td: +PREFIX dc: +PREFIX rdf: +SELECT DISTINCT ?id ?title ?desc +WHERE { + ?id rdf:type td:Thing; + dc:title ?title; + dc:description ?desc. + FILTER(contains(?desc, "${query}")). +} +LIMIT 100 +``` +(`${query}` = input from Node-RED search UI) + +## Related Documents and Links +* [Draft result](https://github.com/k-toumura/document-for-wot/blob/master/2021-10-01-nodered-directory-ktoumura.pdf) + +* The slides used in Openday (Oct 11) can be found below: + * [PowerPoint](https://github.com/w3c/wot/blob/main/PRESENTATIONS/2021-10-online-f2f/2021-10-11-WoT-F2F-Openday1-ktoumura.pptx) + * [PDF](https://github.com/w3c/wot/blob/main/PRESENTATIONS/2021-10-online-f2f/2021-10-11-WoT-F2F-Openday1-ktoumura.pdf) \ No newline at end of file diff --git a/events/2021.09.Online/RESULTS/README.md b/events/2021.09.Online/RESULTS/README.md index a04b67f3..54ed4493 100644 --- a/events/2021.09.Online/RESULTS/README.md +++ b/events/2021.09.Online/RESULTS/README.md @@ -1,3 +1,13 @@ # Summary of Results from 2021.09 WoT Plugfest +## Projects + +* [Node-RED integration (SPARQL query)](./Node-Red%20integration%20(SPARQL%20query)/README.md) * [Geolocation](Geolocation) +* [Siemens / Logilab TDD](Siemens-LogiLab-TDD) +* [SDF Conversion](SDF-Conversion) +* [Shadow Proxy - Fujitsu](ShadowProxy) +* [Hypermedia protocol proposal 3](Hypermedia) +* [WoT Device Emulator](WoT-Device-Emulator) +* [UPM / WoT Hive directory](UPM-WoTHive-Directory) +* [TM Composition](TM-Composition) \ No newline at end of file diff --git a/events/2021.09.Online/RESULTS/SDF-Conversion/README.md b/events/2021.09.Online/RESULTS/SDF-Conversion/README.md new file mode 100644 index 00000000..d3df12a1 --- /dev/null +++ b/events/2021.09.Online/RESULTS/SDF-Conversion/README.md @@ -0,0 +1,21 @@ +# SDF Conversion + +## Description +Add SDF models from the [oneDM playground](https://github.com/one-data-model/playground) to the plugfest directory which have been converted to TMs using my [sdf-wot-converter](https://github.com/JKRhb/sdf-wot-converter-py). For reducing redundancy, the models were added as a submodule pointing to a [separate repository](https://github.com/JKRhb/onedm-playground-wot-tm) + +## Participants + +* Jan Romann (@JKRhb) +* Michael McCool (@mmcool) + +## Discussion + +* would be useful to have a link back to the source data (a general issue when one thing is generated from another) and also to name the corresponding sdf model +* not clear how exactly to map sdfObjects to TM modularity; currently flattening +* accelerometer is a possible candidate for a geolocator; can it be annotated with the proposed geolocation ontology? +* some issues as well with vector values being provided component by component. Are these measured at the same time, or different time? Are they registered, and if so, should there be an action to trigger a "reading"? +* schemas that can group elements of a vector (or label them) would be useful + +## Related Documents and Links + +* [Related PR](https://github.com/w3c/wot-testing/pull/177) diff --git a/events/2021.09.Online/RESULTS/ShadowProxy/README.md b/events/2021.09.Online/RESULTS/ShadowProxy/README.md new file mode 100644 index 00000000..0d2ec518 --- /dev/null +++ b/events/2021.09.Online/RESULTS/ShadowProxy/README.md @@ -0,0 +1,17 @@ +# Shadow Proxy - Fujitsu + +## Description + +Shadow Proxy - Fujitsu + +## Participants + +* Ryuichi Matsukura (@mryuichi) + +## Related Documents and Links + +* [Related PR](https://github.com/w3c/wot-testing/pull/181) + +* The presentation slides: + * [PDF](https://github.com/mryuichi/documents/blob/master/Fujitsu-plugfest-TPAC2021.pdf) + * [PPT](https://github.com/mryuichi/documents/blob/master/Fujitsu-plugfest-TPAC2021.pptx) diff --git a/events/2021.09.Online/RESULTS/Siemens-LogiLab-TDD/README.md b/events/2021.09.Online/RESULTS/Siemens-LogiLab-TDD/README.md new file mode 100644 index 00000000..bfd7d3bd --- /dev/null +++ b/events/2021.09.Online/RESULTS/Siemens-LogiLab-TDD/README.md @@ -0,0 +1,406 @@ +# Siemens / Logilab TDD + +## Description + +Siemens in cooperation with Logilab provides a Thing Description Directory endpoint for discovery testing: + +* https://siemens-wot.demo.logilab.fr/ +* Using Apache Jena Fuseki as triple-store database +* Partially implementing TDD API + +```javascript +{ + "@context":[ + "http://www.w3.org/ns/td", + "https://w3c.github.io/wot-discovery/context/discovery-context.jsonld" + ], + "@type":"DirectoryDescription", + "title":"Thing Description Directory (TDD)", + "version":{ + "instance":"1.0.0-alpha" + }, + "securityDefinitions":{ + "no_sec":{ + "scheme":"nosec" + } + }, + "security":"no_sec", + "base":"https://siemens-wot.demo.logilab.fr", + "actions":{ + "createTD":{ + "description":"Create a Thing Description", + "uriVariables":{ + "id":{ + "title":"Thing Description ID", + "type":"string", + "format":"iri-reference" + } + }, + "forms":[ + { + "href":"/td/{id}", + "htv:methodName":"PUT", + "contentType":"application/td+json", + "response":{ + "description":"Success response", + "htv:statusCodeValue":201 + }, + "additionalResponses":[ + { + "description":"Invalid serialization or TD", + "contentType":"application/problem+json", + "htv:statusCodeValue":400 + } + ], + "scopes":"write" + }, + { + "href":"/td", + "htv:methodName":"POST", + "contentType":"application/td+json", + "response":{ + "description":"Success response", + "htv:headers":[ + { + "description":"TD ID or System-generated UUID (version 4) URN", + "htv:fieldName":"Location", + "htv:fieldValue":"" + } + ], + "htv:statusCodeValue":201 + }, + "additionalResponses":[ + { + "description":"Invalid serialization or TD", + "contentType":"application/problem+json", + "htv:statusCodeValue":400 + } + ], + "scopes":"write" + } + ] + }, + "updateTD":{ + "description":"Update a Thing Description", + "uriVariables":{ + "id":{ + "title":"Thing Description ID", + "type":"string", + "format":"iri-reference" + } + }, + "forms":[ + { + "href":"/td/{id}", + "htv:methodName":"PUT", + "contentType":"application/td+json", + "response":{ + "description":"Success response", + "htv:statusCodeValue":204 + }, + "additionalResponses":[ + { + "description":"Invalid serialization or TD", + "contentType":"application/problem+json", + "htv:statusCodeValue":400 + } + ], + "scopes":"write" + } + ] + }, + "deleteTD":{ + "description":"Delete a Thing Description", + "uriVariables":{ + "id":{ + "title":"Thing Description ID", + "type":"string", + "format":"iri-reference" + } + }, + "forms":[ + { + "href":"/td/{id}", + "htv:methodName":"DELETE", + "response":{ + "description":"Success response", + "htv:statusCodeValue":204 + }, + "additionalResponses":[ + { + "description":"TD with the given id not found", + "contentType":"application/problem+json", + "htv:statusCodeValue":404 + } + ], + "scopes":"write" + } + ] + } + }, + "properties":{ + "retrieveTD":{ + "description":"Retrieve a Thing Description", + "uriVariables":{ + "id":{ + "title":"Thing Description ID", + "type":"string", + "format":"iri-reference" + } + }, + "forms":[ + { + "href":"/td/{id}", + "htv:methodName":"GET", + "response":{ + "description":"Success response", + "htv:statusCodeValue":200, + "contentType":"application/td+json" + }, + "additionalResponses":[ + { + "description":"TD with the given id not found", + "contentType":"application/problem+json", + "htv:statusCodeValue":404 + } + ], + "scopes":"read" + } + ] + }, + "retrieveTDs":{ + "description":"Retrieve all Thing Descriptions", + "forms":[ + { + "href":"/td", + "htv:methodName":"GET", + "response":{ + "description":"Success response", + "htv:statusCodeValue":200, + "contentType":"application/ld+json" + }, + "scopes":"readAll" + } + ] + }, + "searchSPARQL":{ + "description":"SPARQL semantic search", + "uriVariables":{ + "query":{ + "title":"A valid SPARQL 1.1. query", + "type":"string" + } + }, + "forms":[ + { + "href":"/search/sparql?query={query}", + "htv:methodName":"GET", + "response":{ + "description":"Success response", + "htv:statusCodeValue":200 + }, + "additionalResponses":[ + { + "description":"Query not provided or contains syntax errors", + "contentType":"application/problem+json", + "htv:statusCodeValue":400 + } + ], + "scopes":"search" + }, + { + "href":"/search/sparql", + "htv:methodName":"POST", + "response":{ + "description":"Success response", + "contentType":"application/sparql-results+json", + "htv:statusCodeValue":200 + }, + "additionalResponses":[ + { + "description":"JSONPath expression not provided or contains syntax errors", + "contentType":"application/problem+json", + "htv:statusCodeValue":400 + } + ], + "scopes":"search" + } + ] + } + } +} +``` + +## Participants + +* Christian Glomb (@wiresio) +* (@Murloc6) +* Kunihiko Toumura (@k-toumura) +* Ege Korkan (@egekorkan) +* Farshid Tavakolizadeh (@farshidtz) +* Daniel Peintner (@danielpeintner) +* Michael McCool (@mmccool) + +## Discussion + +* (@wiresio): + @k-toumura - thanks for testing the TDD api and giving us feedback! + Issues we had with: + * There is no `"@type": "Thing"` in the TD. Then the framing does not know how to handle this since the Thing is supposed to be the exported element. @Murloc6 - please change the default behavior of our TDD assuming that we are always dealing with things. + * Unfortunately we are loosing both "title" and "titles" as well as "description" and "descriptions". @Murloc6 - please check whether we can re-generate at least one of them + +* (@wiresio): + @egekorkan - with respect to "unit" having "%" please see: + + * "unit" with "%" useful for UI generation + * However, is interpreted as part of URI in SPARQL + +* (@Murloc6): + In our implementation I remove the `"@type": "@vocab"` from the context defined here : + This leads to avoid any error from the SparqlEndpoint but if the value is supposed to be an URI this is not stored as is and we loose the opportunity to query this specific URI from adapted SparqlQuery. + Everything is explained here : with some other reflexion from : + +* (@Murloc6): + I tried to import https://github.com/w3c/wot-testing/blob/main/events/2021.09.Online/TD/TDs/Hitachi/hitachi-led.td.jsonld into our implementation of the TDD and I reproduced the error with the title/titles that disappear. I discovered that this is because there is no `https://www.w3.org/2019/wot/td/v1 ` in the `@context`. I can consider that this context is mandatory and add it if it is missing. + +* (@k-toumura): + Thank you for your comment! I've made a PR for fixing our TDs (#172 ). + Examples in current TD Recommendation and Editor's Draft use `http://www.w3.org/ns/td` as `@context` (e.g., [Example 1](https://w3c.github.io/wot-thing-description/#simple-thing-description-sample)). This is somewhat confusing... + +* (@k-toumura): + `securityDefinitions` in original TD has not been correctly restored. For example, [updated our TD](https://github.com/w3c/wot-testing/blob/80c90e4cf2ec01cead7db31057fded5a14a54f89/events/2021.09.Online/TD/TDs/Hitachi/hitachi-led.td.jsonld) contains following `security` and `securityDefinitions`: + + ```json + "securityDefinitions": { + "basic_sc": { + "scheme": "basic", + "in": "header" + }, + "no_sc": { + "scheme": "nosec" + } + }, + "security": [ + "basic_sc" + ], + ``` + + After registering above TD, I got following (invalid) TD as a result: + + ```json + "security": "basic_sc", + "securityDefinitions": { + "@none": [ + { + "@type": "basic", + "in": "header", + "td:securityDefinitionForConfiguration": { + "id": "basic_sc" + } + }, + { + "@type": "nosec", + "td:securityDefinitionForConfiguration": { + "id": "no_sc" + } + } + ] + }, + ``` + +* (@wiresio): + @k-toumura - thanks for reporting! + There is two challenges: + + * If "security" is an array with just one element, we are not returning the array but just the respective element as value. Although it does not yield to the original TD, it is still valid. + * "securityDefinitions" is not restored correctly due to the following: + + ```json + "securityDefinitions": { + "basic_sc": { + "scheme": "basic" + } + }, + "security":["basic_sc"] + ``` + + is translated to RDF + + ```turtle + td:securityDefinitions _:b0 . + _:b0 a wotsec:BasicSecurityScheme . + td:hasSecurityConfiguration . + ``` + + which means that the relation between the configuration basic_sc and the definition _:b0 is lost. + + Therefore we propose to add a new relation _td:securityDefinitionForSecurityConfiguration_ to keep it such as: + + `_:b0 td:securityDefinitionForSecurityConfiguration .` + + For more details, see this issue: + + For the plugfest we are using the "@none" fix/workaround and I'd ask you to work-around this, e.g. by string-replacing the incorrect returned "securityDefinitions" with a correct one in your implementation + +* (@Murloc6): + If it is needed we can disable this workaround for now ? + +* (@k-toumura): + Thank you for your explanation and consideration. + I'm going to write a work-around on our code to handle this. + +* (@wiresio): + Alright, and sorry for needing to work-around a workaround ;-) + +* (@farshidtz): + I think this is based on the old spec. The context path for the registration API should be /things. + +* (@mmcool): + See scripts at but needs to be updated. Note this is a CI script that runs on github, just needs to point at new directory service. @wiresio will do a PR... may need to move the action script to his own repo. + +* (@farshidtz): + > I looked at the script and I discovered that it uses the `/td` routes instead of the `/things` ones. Should we implement both ? + + It's an old script. It should also be changed to `/things`. I'll update them. + +* (@wiresio): + I deployed a new script running at: + + Unfortunately we have issues uploading several TDs. + +* (@k-toumura): + [eCar TD](https://github.com/w3c/wot-testing/blob/main/events/2021.09.Online/TD/TDs/Siemens/ecar.td.jsonld) doesn't have `id`. Because of this, each run of crawling script assigns a new `id` to eCar TD, and then there are many eCar TD in TDD. + +* (@danielpeintner): + > [eCar TD](https://github.com/w3c/wot-testing/blob/main/events/2021.09.Online/TD/TDs/Siemens/ecar.td.jsonld) doesn't have `id`. Because of this, each run of crawling script assigns a new `id` to eCar TD, and then there are many eCar TD in TDD. + + I created a PR so that eCar has an id. Hope this helps + +* (@wiresio): + Thanks @k-toumura for reporting! This is definitely an issue to be solved. + + Thanks @danielpeintner for helping to fix it during the plugfest! + + ~~Currently we cannot upload several TDs - probably only those which have an array as "@context".~~ + +* (@farshidtz): + > [eCar TD](https://github.com/w3c/wot-testing/blob/main/events/2021.09.Online/TD/TDs/Siemens/ecar.td.jsonld) doesn't have `id`. Because of this, each run of crawling script assigns a new `id` to eCar TD, and then there are many eCar TD in TDD. + + In previous plugfests, we handled this by having TTLs that are same as the sync interval. This way, old anonymous TDs would automatically get purged from the directory. + + In the script, you can see that a `ttl` is injected inside all TDs. This has to change to `registration.ttl`. See https://w3c.github.io/wot-discovery/#example-expirable-enriched-td + +* (@wiresio): + Thanks @farshidtz - we'll try to introduce a cleanup. + + All TDs should be in TDD now. + +* (@wiresio): + ~~`/things` is currently taking a long while running into a timeout.~~ + + Working now due to using "chunked transfer encoding" :-) + + However, you should be able to retrieve TDs via `/things/{id}` and search via `/search/sparql`. + +* (@farshidtz): + I've updated the sync script to make it inline with the current spec: diff --git a/events/2021.09.Online/RESULTS/TM-Composition/README.md b/events/2021.09.Online/RESULTS/TM-Composition/README.md new file mode 100644 index 00000000..62eab8f4 --- /dev/null +++ b/events/2021.09.Online/RESULTS/TM-Composition/README.md @@ -0,0 +1,24 @@ +# TM Compostion + +## Description + +The [PR](https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1207.html#thing-model-composition) introduces a new feature about Thing Model composition. + +During PlugFest, [examples](https://github.com/w3c/wot-testing/tree/main/events/2021.09.Online/TD/TMs/Siemens) were created to gain experience with this modeling concept and to generate TD instances. + +During the vF2F Thing Description session, a short [presentation](https://github.com/w3c/wot/blob/main/PRESENTATIONS/2021-10-online-f2f/2021-10-07-WoT-F2F-TD-Kaebisch.pdf) was provided (slide 7). + +## Result + +* so far, the composition feature works quite smoothly +* maybe we can rethink about alternative names for "instanceName" + +## Next steps + +* composition should be also supported by the ediTDor tool + +## Related Documents and Links + +* [Related PR](https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1207.html#thing-model-composition) +* [Examples](https://github.com/w3c/wot-testing/tree/main/events/2021.09.Online/TD/TMs/Siemens) +* [Presentation](https://github.com/w3c/wot/blob/main/PRESENTATIONS/2021-10-online-f2f/2021-10-07-WoT-F2F-TD-Kaebisch.pdf) diff --git a/events/2021.09.Online/RESULTS/UPM-WoTHive-Directory/README.md b/events/2021.09.Online/RESULTS/UPM-WoTHive-Directory/README.md new file mode 100644 index 00000000..af64cce5 --- /dev/null +++ b/events/2021.09.Online/RESULTS/UPM-WoTHive-Directory/README.md @@ -0,0 +1,27 @@ +# UPM / WoT Hive directory + +## Description + +From the Ontology Engineering Group at the Universidad Politécnica de Madrid (UPM) we have implemented a Thing Description Directory following the current discovery specification called WoT Hive. + +* The [documentation](https://github.com/oeg-upm/wot-hive/wiki), source code, and latest releases are available in the [WoT Hive github](https://github.com/oeg-upm/wot-hive/). +* Find a deployed WoT Hive in this [link](https://wothive.linkeddata.es/api/things) + * Behind this deployment we are using a RDF4J triplestore that does not support identifiers like `900de665-6a0b-4d48-abcb-2fb457015ba1`, instead add a prefix like `uuid:900de665-6a0b-4d48-abcb-2fb457015ba1`. This issue is due to the triplestore used by the WoT Hive not the directory itself, other triplestores support the former ids. +* For a quick local docker deploy + +````yaml +version: '2' +services: + triplestore: + image: acimmino/helio-cloud-rdf4jstore:latest + ports: + - '4567:4567' + wothive: + image: acimmino/wot-hive:latest + ports: + - '9000:9000' +```` + +## Participants + +* Andrea Cimmino Arriaga (@AndreaCimminoArriaga) diff --git a/events/2021.09.Online/RESULTS/WoT-Device-Emulator/README.md b/events/2021.09.Online/RESULTS/WoT-Device-Emulator/README.md new file mode 100644 index 00000000..2cf374e2 --- /dev/null +++ b/events/2021.09.Online/RESULTS/WoT-Device-Emulator/README.md @@ -0,0 +1,15 @@ +# WoT Device Emulator + +## Description + +* An emulator application to turn an Android device into a virtual WoT device. +* Place a virtual WoT device in a real space and have it actually present media. +* Verify use cases in which media and various devices are coordinated, including devices that do not currently support IP control. + +## Participants + +* Hiroki Endo (@endouhhc) + +## Related Documents and Links + +* [Presentation](https://github.com/w3c/wot/blob/main/PRESENTATIONS/2021-10-online-f2f/2021-10-11-WoT-F2F-OpenDay1-Endo.pdf) diff --git a/events/2022.02.Online/README.md b/events/2022.02.Online/README.md index 699bd8c8..0f929016 100644 --- a/events/2022.02.Online/README.md +++ b/events/2022.02.Online/README.md @@ -1,2 +1,3 @@ # WoT February 2022 Plugfest/Testfest + Tentatively scheduled for 7-11 February 2022.