<scribe> scribenick: dsr

Sebtastian introduces the metamodel and the discussions arising from the plugfests

This time, we introduced a shared repository for thing descriptions.

The implementations were mainly for HTTP plus a few for CoAP.

as well as some WebSockets and MQTT implementations.

(Sebastian to link his slides later)

Some technical questions arising, e.g. whether to provide the local or external IP address, how to indicate data types with ranges, access control, decoupling semantics from link relation types

This morning we will go through the agenda topics on the wiki. This afternoon a joint session, and tomorrow …

Karsten: how do we get IP addresses of components

URIs provide IP addresses

We need to distinguish local network and public internet addresses

In respect to security, not everyone may be allowed to access all resources on a given device

For links, what is the mapping from link names to RDF URIs

For relative links we need a base URI

Carsten: thing descriptions should be able to specify an explicit base URI
... long discussion on communication metadata …

In summary, we need communication metadata for each platform. The vocabulary will depend on the platform. URIs are useful, but may not always be sufficient. In some cases, it will be necessary to query the platform to get the details, e.g. the URIs for specific thing properties, or a named recipe (set of rules) for constructing these URIs.

The communications metadata could also allow a server to map application layer queries for specific sensors, to platform specific handling of multiplexed data comprising data from many sensors.

We then switched over to the technology landscape. We agreed to put the table on “ice” for now and to request input on each technology. We assigned owners to each technology - see the updated github page.

<vcharpenay> Soumya: topic: discovery/filtering-relevant information needed from a Thing Description?

<vcharpenay> open question. First, other topic.

Thing vs. Server metadata

<vcharpenay> (suggested by Dave)

<vcharpenay> Dave: WoT -> platform of platforms. Distributed.

<vcharpenay> two kinds of developers: app dev (using scripting on a given platform) vs. platform dev

<vcharpenay> therefore, different levels of metadata. Threefold: things/communications/security

<vcharpenay> minimal set of core metadata along those three dimensions?

<Soumya> Dave: Extra info for discovery could be determined by the server

<Soumya> Can included sleep time for example

<Soumya> trade off between laterncy and buffering .... (in relation to the best practices)

<vcharpenay> Matthias: view of TF-DI on discovery? Concrete problems?

<vcharpenay> TD Repository was done in TF-TD and already supports queries. Did TF-DI emerge with other discovery mechanisms?

<vcharpenay> Ex: printer needed in a certain room with certain properties (resolution > x dpi)

<vcharpenay> Darko: requires additional/domain-dependent knowledge (about printers in this case)

<vcharpenay> Extension of the TD model, e.g. with SSN. At the moment {td: {type: Property, name: "BrighnessSensor"}}

<vcharpenay> better to have {td: {type: ssn:Sensor...}}

<vcharpenay> Sebastian: <presentation of the "triple search" feature of the TD Repo>

<vcharpenay> is still limited.

<vcharpenay> Soumya: How/when to get information from the TD if not discovered yet? Different scenarii:

<vcharpenay> https://www.w3.org/WoT/IG/wiki/Discovery_Categories_and_Tech_Landscape

<vcharpenay> finding things in a network (see link above). Concept of Social network of things.

<vcharpenay> Question to Martin.

<vcharpenay> Martin: there is little that has been made @ oneM2M for discovery.

<vcharpenay> 1. String match, 2. SPARQL using annotations (see presentation yesterday)

<vcharpenay> Semantic-based discovery (see link). Keyword to formal concepts

<vcharpenay> Dave: Thingsonomy, people tag things

<vcharpenay> Soumya: moving to the next topic: filtering

<vcharpenay> guidelines from TF-TD to that respect?

<vcharpenay> Dave: 1. server-side SPARQL query, 2. Client-side gathering of TDs and SPARQL, 3. higher-level platform

<crispus> Martin: Release 1 of oneM2M has only simple String matching for discovery of oneM2M resources, Release 2 enables semantic discovery based on filter in SPARQL which is applied to semantic description

<vcharpenay> where to filter? RDF: already a lot of solutions

<vcharpenay> Soumya: CoRE Link format should also be supported

<vcharpenay> and possibly others

<vcharpenay> [Maxime spoke between Martin and Soumya]

<vcharpenay> Carsten: point: never standardized Google Search. Need for a unified search mechanism?

<vcharpenay> Anyway, CoRE Link format would benefit from a higher abstraction level for querying.

<vcharpenay> Maxime: target the Semantic Web, define an ontology, use existing mechanisms and wrap them over other formats like CoRE Link

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: dsr
Inferring Scribes: dsr
Present: Mohammed

WARNING: Fewer than 3 people found for Present list!


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 27 Jan 2016
Guessing minutes URL: http://www.w3.org/2016/01/27-wot-td-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.