- From: Phil Archer <phila@w3.org>
- Date: Wed, 21 Sep 2016 08:58:57 +0100
- To: SDW WG Public List <public-sdw-wg@w3.org>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>
The minutes of day two of our face to face at TPAC 2016 are at
https://www.w3.org/2016/09/20-sdw-minutes, linked from the agenda and
pasted below as text for convenience.
Thanks to Andrea for spotting the RRSAgent problem, I was able to create
a full set of minutes.
Spatial Data on the Web WG F2F, TPAC 2016 Day 2
20 Sep 2016
Attendees
Present
eparsons, AZ, ahaller2, RaulGarciaCastro, AndreaPerego,
kerry, raphael, Linda, frans, billrobe_, jtandy,
dmitrybrizhinev, BartvanLeeuwen, jonblower, DanhLePhuoc,
Maxime, billroberts, Achille, DarkoAnicic, victor,
chunming, andreic, Sebastian_Kaebisch@Siemens
Regrets
Chair
eparsons
Scribe
Linda, billroberts, phila, AndreaPerego
Contents
* [2]Topics
1. [3]SSN
2. [4]SOSA core goals
3. [5]SSN top-down
4. [6]What topics are modules built around?
5. [7]SSN Use Cases & Requirements
6. [8]https://www.w3.org/2015/spatial/track/issues/78
7. [9]What topics are modules built around? (for real
this time)
8. [10]'RecordOfObservation' vs 'ActivityOfObserving'
9. [11]Future Face to face meetings
10. [12]Joint Session with WoT IG
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<eparsons> trackbot, start meeting
<eparsons> Still waiting for people to arrive - may start in
about 10 mins est. Time for a coffee ?
<phila> trackbot start meeting
<trackbot> Spatial Data on the Web WG F2F, TPAC 2016 Day 2
<trackbot> Date: 20 September 2016
<billrobe_> Documents we'll be discussing in the first session:
<Linda> scribe: Linda
<billrobe_> [15]http://w3c.github.io/sdw/eo-qb/
[15] http://w3c.github.io/sdw/eo-qb/
<billrobe_>
[16]https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Cover
ages
[16] https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Coverages
<billrobe_> [17]http://w3c.github.io/sdw/coverage-json/
[17] http://w3c.github.io/sdw/coverage-json/
<billrobe_> (sorry my irc client has mangled my username)
<eparsons> Topic : Approve yeterdays minutes
<eparsons> PROPOSED : Approve yesterdays minutes
<eparsons> [18]https://www.w3.org/2016/09/19-sdw-minutes.html
[18] https://www.w3.org/2016/09/19-sdw-minutes.html
<jtandy> +1
<eparsons> +1
+1
<billrobe_> +1
<kerry> +1
<AndreaPerego> +1
<eparsons> RESOLUTION : Approve yesterdays minutes
<raphael> +1
<ahaller2> +1
<frans> +1
<RaulGarciaCastro> +1
<eparsons> Topic : Coverage (demos and review of ed drafts)
Bill: will bring everyone up to date of the last few months'
work
... around using datacube for coverage data
... an australian team is working on that, Sam will talk about
it
... and in a different strand roba is working on it
<billrobe_> [19]http://w3c.github.io/sdw/eo-qb/
[19] http://w3c.github.io/sdw/eo-qb/
Bill: the doc at this link will become a w3c note
<billrobe_>
[20]https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Cover
ages
[20] https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Coverages
Bill: roba's work is in this wiki page, could become part of
the first doc
... also Jon Blower will join and tell us about CoverageJSON
<billrobe_> [21]http://w3c.github.io/sdw/coverage-json/
[21] http://w3c.github.io/sdw/coverage-json/
Bill: this will also be a W3C note and OGC discussion paper
<billrobe_> [22]https://covjson.org/
[22] https://covjson.org/
Bill: we're not trying to replace existing cov standards but
targetting new users
sam: using rdf datacube for coverages
... rdf + triple store doesn't work for large coverages
... 3 ways of doing this with rdf
dmitrybrizhinev: been working on an example which is in the
draft note
<billrobe_>
[23]https://github.com/ANU-Linked-Earth-Data/ontology/blob/mast
er/ANU-LED.owl
[23]
https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED.owl
dmitrybrizhinev: using rdf to say things about your data
<billrobe_>
[24]https://github.com/ANU-Linked-Earth-Data/ontology/blob/mast
er/ANU-LED-example.owl
[24]
https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED-example.owl
dmitrybrizhinev: the example helps you understand how to do it
<RaulGarciaCastro> The second file should be a .ttl file,
shouldn’t it?
<dmitrybrizhinev> yes, they both probably should be
kerry: suggests a demo showing the work, people here haven't
seen it
<sam> [25]https://anu-linked-earth-data.github.io/#/
[25] https://anu-linked-earth-data.github.io/#/
(just a moment while we get the beamer working)
billrobe_: we got the demo on screen now
sam: its a javascript application
... data stored on the server in rdf
... you can move through time
... backend supports directly querying the rdf
<jonblower> I don't suppose the screen can be shared through
Webex? Demo link works but might be easier to follow if we
could see what Sam's doing
kerry: it was difficult to understand you so I will rephrase
<sam> I can try poking around in WebEx to see whether screen
sharing works.
<jonblower> Thanks Sam. Actually I could hear you better than I
can hear Kerry now!
kerry: data is stored as binary pixels and every tile has an
url where you can get image details
<billrobe_>
[26]https://github.com/ANU-Linked-Earth-Data/ontology/blob/mast
er/ANU-LED-example.owl
[26]
https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED-example.owl
<sam> Yes, that's the one. Thanks.
sam: the example makes it clear.
kerry: the ontology here is describing this dataset
... roba is more looking at standardizing the dimensions
<AndreaPerego> JSON output from one of the queries:
[27]https://anulinkedearth.org/landsat/query?query=PREFIX+xsd:+
%3Chttp:%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23%3E%0APREFIX+led:
https://anulinkedearth.org/landsat/query?query=PREFIX+xsd:+<http://www.w3.org/2001/XMLSchema#>
+%3Chttp:%2F%2Fwww.example.org%2FANU-LED%23%3E%0APREFIX+geo:+%3
Chttp:%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%0APR
EFIX+qb:++%3Chttp:%2F%2Fpurl.org%2Flinked-data%2Fcube%23%3ESELE
CT+%3Fsubject+%3FgeoSparql+%3FtimePeriod+%3Fband+%3Fvalue+%3Fre
solution+%3Flon+%3Flat+%3FdggsLevelSqua[CUT]
kerry: the work also has a prov alignment and some ssn
... and a bit of owl time
billrobe_: rob please give us an overview of your work
<billrobe_>
[28]https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Cover
ages
[28] https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Coverages
roba: looked at rdf datacube and how to add in dimensions via
an extension
... the work is still in strawman stage
(showing roba's screen)
scribe: flattened out dimension hierarchy to make it simpler to
use
... as a single file
... communities can define their own dimensions
... and register them
<Zakim> phila, you wanted to ask about validation
<sam> (some example Turtle from demo before:
[29]http://pastebin.com/DUrGGiNj)
[29] http://pastebin.com/DUrGGiNj)
phila: you have some spin in there to validatie
... can I check that my data is valid to your templates?
<billrobe_> (thanks sam for the example data)
roba: would be possible to make a validation spin, this is an
entailment spin
(shows the UI letting you add a coordinate dimension binding
using a form)
phila: are you depending on spin for this to work?
roba: not particularly, backend could use anything
billrobe_: Rob is explicitly asking for feedback on this
... Sam and Dmitri also welcome feedback
... let's move on to coveragejson work
jonblower: doing this work in the context of Melodies project
... aim is to publish scientific data on the web in a way which
lets web developers use it
... coveragejson is the data format we developed for this
... not oversimplified compared to eg NetCDF, but with linking
capabilities etc
... specification, tools and libraries. The website the screen
is showing is the frontend.
... also a cookbook, the best starting place.
... and a playground
... explains the covjson format
<billrobe_> [30]https://covjson.org/playground/
[30] https://covjson.org/playground/
jonblower: several strategies for when the data gets big
... (missed the first one)
... you can tile the data, split it up in multiple ways
<maik> (bug with Safari, try in Chrome/Firefox)
jonblower: tools: js library for reading the format, plugin for
leaflet, plugin for WIP virtual globe
... and others
<billrobe_> [31]http://w3c.github.io/sdw/coverage-json/
[31] http://w3c.github.io/sdw/coverage-json/
jonblower: we have a draft Note we're working on
includes some thoughts on converting the covjson to RDF
scribe: using JSON-LD
... its limited, parts like domain and range are difficult
billrobe_: how do you see this in relation to existing OGC
standards?
jonblower: its an encoding format, not tied to OGC or others.
But with mapping between covjson and CIS its possible to use it
with OGC services
... one dif is in covjson we allow multiple CRS.
... covjson is similar to datacube and a mapping between them
would be interesting
frans: how is metadata handled?
<frans> How interoperable are the different coverage solutions
on the metadata level?
jonblower: you have to decide how deep you want to go with
metadata. At a minimum define the units of measure and things
your measuring.
... not sure theres a single metadata set that fits everybody.
Roba's profiles could be interesting.
<Zakim> jtandy, you wanted to ask about the structure of the
value arrays
jtandy: a colleague has been using the spec to test it. He said
the value range is always a single dimensional array, have you
tried multidimensional?
jonblower: decided it would be a bad idea to do this in json.
<frans> Isn't this a possible solution for the requirement to
have quality metadata for each value?
jonblower: with a single dimension array it's always trivial to
check if it fits, with multi dimensional or nested arrays its
difficult
<Zakim> phila, you wanted to ask about relative merits of each
approach
phila: we're sort of looking at two things at different stages
of maturity here: covjson has had more work put in than the ANU
work
... how to decide which approach is better?
... is it possible to converge or bridge?
jonblower: there's no competition in my eyes. We use JSON
because that's where web developers live.
... roba and ANU have nice work on making these things more
generic and richer
<frans> Could having the same metadata model allow convergence?
Kerry: the ANU team came from a different direction.
... roba's formalizing dimensions for datacube
eparsons: we're having connectivity problems
billrobe_: we should ask ourselves who it's for. That should
help with choosing.
... the spec should spell out what the target audience is for
each approach
<eparsons> sorry connectivity problems in Lisbon
<Zakim> billrobe_, you wanted to ask about linking
jonblower: not too much choice though, a standard with too much
choice is too difficult to implement.
... profiles would help
<Zakim> roba, you wanted to discuss RDF QB role
roba: there is a vocabulary for describing dimensions and
measures
... the way to handle dimensions should be the same in covjson
and RDF DQ, ie we should work on a mapping
jonblower: true. The current mapping to RDF is not well
developed, we should look at it more seriously in this light.
... also, interoperability is lossy.
<phila> issue: alignment between CoverageJSON and EO-QB for
metadata, etc. What does the @context file for CovJson lead to
<trackbot> Created ISSUE-79 - Alignment between coveragejson
and eo-qb for metadata, etc. what does the @context file for
covjson lead to. Please complete additional details at
<[32]http://www.w3.org/2015/spatial/track/issues/79/edit>.
[32] http://www.w3.org/2015/spatial/track/issues/79/edit
jtandy: in the BP session we were trying to help people choose
the right format for their data.
... covjson could be an example of making the right choices.
jonblower: will be at metoffice in october, we chould have a
chat about it
billroberts: in covjson you can have a collection of coverages
and there's a tiled approach, with each tile having a URL.
... is there a formalism for using fragment identifiers within
a coverage?
... identifying a data point or a slice or dice is useful.
jonblower: we've talked about extracts/subsets.
bill roberts: issue 66 on github
jonblower: are looking at identifiers for extracts, not an API
for doing this
... works in coverage world, maybe not in general world. Not
sure it will make it into the spec, not really mature.
bill roberts: it would address the linkability requirement
kerry: Chris Little has been talking about having named dices
<Zakim> phila, you wanted to ask about MIME type registration
kerry: could be considered to do something like this
... not native DQ
... in ANU solution you can do sparql queries as well so user
is able to get their own abstract, but this may be an
unattractive solution.
<jonblower> Here's the issue on the CovJSON GitHub:
[33]https://github.com/covjson/specification/issues/66
[33] https://github.com/covjson/specification/issues/66
jonblower: like Kerry thinking to have rectangular extracts
<eparsons> billroberts Working on FPWD
<eparsons> Kerry - Feedback on template requested
<eparsons> kerry : Style in particular
<eparsons> phila_ : No use of "click here" please
<eparsons> phila_ Link should be name of doc for example
<eparsons> phila_ Are mime times registered for covJSON ?
<eparsons> jonblower No but help would be great...
<eparsons> phila_ w3c process will be shared
<Werk_> [34]https://www.w3.org/QA/Tips/noClickHere
[34] https://www.w3.org/QA/Tips/noClickHere
<jonblower> apologies that I can't return after the coffee
break, I will be travelling, then
<jonblower> in meetings
<eparsons> scribe: billroberts
SSN
kerry: The SSN ontology was built some time ago through a W3C
incubator group.
... the objective of the SDW group in its charter is to deliver
the SSN ontology as a standard
... and to modularise it to make it simpler to use
... This is on the REC track so we need at least two
implementations of every term in the ontology
<AZ> I don't hear anything, can someone in Lisbon connect to
the webex
kerry: and that has to be complete 7 months from now
... We'll do that using a survey, to ask people if/how they are
using each term
(Ed is trying to reconnect the webex)
scribe: Also we have agreed that any variants will be backward
compatible to previous uses of SSN
... Other things in the landscape - there is a lot of demand
and fast moving implementations in the Internet of Things area
... many people are using SSN, but there is criticism about the
size and complexity, so the modularisation should address that
issue
... Later today, the Web of Things working group is joining us
for 2 hours.
... In summary, I think we are going too slowly, and perhaps
concentrating on the wrong things.
SOSA core goals
kerry: We decided early on to remove DOLCE from the ontology as
it is a major challenge for usability
... there is a proposal for a core of SOSA. Armin will
introduce
<ahaller2> [35]http://w3c.github.io/sdw/ssn/#Modularisation
[35] http://w3c.github.io/sdw/ssn/#Modularisation
ahaller2: We propose a vertical modularisation. The details of
naming in the SSN document are a little out of date but don't
worry about that
... the outer layers in the diagram at the above link are
importing a lightweight core
... So it could be reused easily in other things, eg schema.org
or Web of Things
... SSN module will import the core as an ontology and extend
it with concepts around sensor networks
<ahaller2>
[36]https://www.w3.org/2015/spatial/wiki/SOSA_Ontology
[36] https://www.w3.org/2015/spatial/wiki/SOSA_Ontology
ahaller2: work so far is currently on the wiki
... listing classes and properties that are included in the
core
... It's a dumbed-down version of SSN with one or two extra
things
... These classes already exist in SSN, so SSN can import this
core with conflict to the semantics of SSN
... There are no axioms in the core, to keep it lightweight
... the wiki page is the consensus of the working group members
that have been closely involved
DanhLePhuoc: we'll need alignment or cross-linking from the new
namespace to the old namespace to support people who made
queries etc that used the old namespace
ahaller2: that alignment can be done in the higher level
ontologies such as SSN
DanhLePhuoc: to support adoption we should do that alignment
and support existing users
ahaller2: the main part of SSN will be untouched, so that
should cover people using the old namespace. They can
transition to the new namespace if they want but they don't
have to
kerry: we should have everything in one namespace and it should
be the new SSN namespace
RaulGarciaCastro: the SSN ontology is the de facto standard. We
take the risk of creating a new competing standard.
... (and by the way 'SOSA' in Spanish means dull or boring!)
... there have been decisions on conceptualisation,
implementation, modularisation. It would be easier to discuss
if it could be divided up a bit
kerry: agrees with Raul's point
... there are a lot of changes, potentially confusing ones
... we should start with SSN, pull it apart, then look
individually at the various extensions
... It's not an option to use the old namespace. Best option
would be to convert all terms to the same new namespace
... Separating out the core to a different namespace could be
confusing
ahaller2: the namespace is not really important. SSN namespace
has to change and there will be a link back to the old one
... the editors have proposed a core which is as simple and
reusable as possible.
... we can discuss the choice of specific terms according to
feedback
... but I don't think we need to go back to the start. Just to
discuss questions about the choice of individual terms
<Zakim> raphael, you wanted to remind what's happen with the
vcard namespace mess
raphael: regarding the two namespaces for SSN, something
similar happened in the past with Vcard. There were 2
namespaces and it caused confusion for years as no-one knew
which to use
phila: W3 process does not prevent use of purl.org as a
namespace, but there are technical issues around use of purl,
which looks like it is not going to be maintained
... purl redirects to a W3 URL. We could perhaps set up a
redirect from that to some new place
Maxime: I am working in a European project with a large
versioned vocabulary. We had one namespace that linked to
multiple documents, each defining a set of concepts
... so there is no technical issue in having one namespace and
separate modules in separate files
ahaller2: the namespace choices were not really technical but
because of the concepts addressed in the core, which are not
really SSN realted
<Zakim> jtandy, you wanted to note that the sosa-core seems
like it's simple enough to pick up and use even if you're not
deep into RDF/OWL - which I like ...
jtandy: I like the work on the core - it's simple for
developers to use without having to worry about the axioms/Owl
aspects.
<DanhLePhuoc> +q
<Zakim> phila, you wanted to talk about cores and timing
phila: do you have a stable core that you are happy with and
that is widely used? Are the non-core aspects less stable or
less used?
kerry: no, the other way round. The 'extensions' are stable and
used. The core is new so not yet used
phila: reminder that we only have 9 months left. This is on REC
track so needs implementations and that takes time. You'll need
to enter candidate-REC by Feb or March latest. So with
holidays, that's only 2.5 working months left
... so needs decisions soon. Best to focus on what is known to
be used and needed for the REC
... you've done a lot of work. Publish it soon
DanhLePhuoc: returning to the bridge to the old ontology, doing
the alignment work is important for driving use
... we need to demonstrate that it is really backward
compatible, or we'll end up with another different standard
ahaller2: the new SSN plus an import of the unchanged DULCE
extension will be the same as the old stuff
DanhLePhuoc: I have a lot of sensors and data using the old
vocab.
... querying a mix of old and new will lead to very messy
queries
RaulGarciaCastro: best thing would be new ontology and
mappings. But in terms of timing, that is two new deliverables.
Is that feasible?
ahaller2: so Danh's proposal is having two ontologies both with
links back to old terms. Plus a Best Practice document
explaining how to use
... for modularisation, should they go in new sub-sections of
the namespace?
DanhLePhuoc: even changing of labels may cause backward
compatibility issues
ahaller2: the description has to change because the semantics
has changed - but it is in a new namespace, so it's a different
term
DanhLePhuoc: lots of developers do text search and regular
expressions to find data - they might not use URIs
ahaller: the label in SSN doesn't change. Just the core
DanhLePhuoc: but confusing for people if there are two very
similar but distinct terms
kerry: if you are using a lightweight part of SSN, you probably
want it to be compatible with the rest of SSN, otherwise you
wouldn't use SSN
... are people going to understand what is intended by a term?
if they are doing lightweight work, they will probably not do
any reasoning, just want a properly defined term to use
DanhLePhuoc: different levels of semantic info: RDFS, OWL,
semantic rules. Depends on the capability of your processor
Maxime: methodology to modularise: this should be led by some
requirements. Modules could define alignment to old ontology.
Another could define alignment to DUL
... could be a module to talk about actuators for example.
Should that be aligned to the old ontology?
... comments and labels found in the new namespace might be
different to the old ones
... at lower levels there could be simpler descriptions of
terms
... technically I'm not sure we need a new namespace
<ahaller2> [37]http://purl.oclc.org/NET/ssnx/ssn#Property
[37] http://purl.oclc.org/NET/ssnx/ssn#Property
ahaller2: I agree with you about labels. We need to change
labels because the old ones referenced DULCE and we're taking
that out.
kerry: also there are lots of spelling mistakes that need fixed
ahaller2: we haven't yet decided on specific namespaces, only
that they will be 'slash' namespaces. Maxime's suggestion on
implementation sounds good
... we have changed descriptions of the terms in the core
because they have much more lightweight semantics
... and we have to remove references to other terms that will
not be in the core
BartvanLeeuwen: should we record the things in the minutes
where we have consensus? Lots of discussions but we're not
recording the conclusions
<Maxime> Requirement: have a core module that is very
lightweight
<Maxime> Requirement: have other modules that are alignemnts to
the old version of SSN.
<Maxime> Requirement: have a module that describe actuators
<Maxime> Requirement: when accessing the new namespace, one
needs to access an ontology that is logically equivalent to the
old ontology, with
<Maxime> the alignement to DUL, and that allows to lead the
same entailments.
<Maxime> Constraint: the descrition of concepts in the
different modules (for instance with/without DUL) cannot be the
same (they will not have the same semantics)
BartvanLeeuwen: are we already talking to IoT people?
kerry: yes
raphael: can we have a simple table that lists the old terms
and what we are doing with each term (eg moving to core, etc)
RaulGarciaCastro: I tried to do that but it was too difficult
raphael: if we can't do that, it is indicating a problem
phila: re spelling mistakes needing correction. We can't change
purl.org but we can change the thing it points to
kerry: plan to leave old stuff as is, and make a new better one
phila: we can probably make things work if it's worth doing
SSN top-down
kerry: early on we pulled out DULCE from the ontology. Several
people didn't like the previous modularisation
... first attempt wasn't right
... a few weeks ago I went back to the original SSN and pulled
out DULCE.
... it changes DULCE to the new namespace for DOLCE which has
changed in the mean time
... uses the new W3 namespace
... From a process point of view, I'd like to start there for
modularisation
... then we can be very explicit about tracking changes and
documenting reasons for changes
... given delivery dates, I'd like to prioritise that before
making any deeper changes
... I think that's the only strategy that will allow us to know
what we're doing and be able to discuss changes one at a time
... let's decide as a group what the modules need to be and
look for volunteers to work on each one
... the modularisation is the most important thing
frans: are you planning to record provenance of terms?
<Zakim> phila, you wanted to ask an awkward question
kerry: old ontology is very good at describing provenance
(AZ - many thanks for the correction and explanation! I think I
was getting confused about those two things)
DanhLePhuoc volunteers to document alignment of new ontology
with existing ontologies including PROV-O and Time
scribe: and coverage
<Maxime> can anyone add me as a collaborator on the github
project ? maximelefrancois86
Maxime: will help on this
kerry: we need to agree what the content of the modules will be
Maxime: we can follow Raul's suggestion of going through the
terms one by one and deciding for each
ahaller2: agree we need to decide what modules
... shouldn't have too many different modules. A lot could be
in main SSN
eparsons: regarding new modules and that you are on the REC
track so need implementations, can you prioritise those parts
that are most likely to be adopted quickly?
kerry: we're talking about terms that are already in use, we're
just moving them around
eparsons: do you have to prove that people are using your new
modularisation? (rather than the old stuff)
kerry: don't think so
<DanhLePhuoc> +q
<eparsons> ack ack next
kerry: we need the modules first, then the extensions
... implementation of extensions is more significant
phila: the things you can get implemented are the bits that go
in the REC track document. You can separate out
not-yet-implemented aspects into a Note or other document
DanhLePhuoc: the previous version was not formally
standardised. Need evidence of implementation of the old terms
phila: would be neater to have separate documents rather than
one document with non-normative sections
... (for implemented and not-yet-implemented parts)
<raphael> The alternative approach presented by Kerry is at
[38]https://github.com/w3c/sdw/tree/gh-pages/ssn/ssn_separated
[38] https://github.com/w3c/sdw/tree/gh-pages/ssn/ssn_separated
kerry: there are few things in there that need urgent
attention.
... and there are some errors in SSN that should be corrected
eparsons: go ahead and fix those errors
general approval from the meeting that kerry should fix the
errors she listed
<raphael> Details are: delete the explicit statements that says
that a concept is a subClassOf owl:Thing (e.g.
FeatureOfInterest)
<raphael> In the DOLCE alignments, PhysicalObject need to be
changed to Objects
<eparsons> +1
<raphael> +1
<DanhLePhuoc> =1
<RaulGarciaCastro> +1
<jtandy> +0 ... not sure of implications
<DanhLePhuoc> +1
<AZ> +1
<phila> +1
<BartvanLeeuwen> +1
<Maxime> prcision: In the DOLCE alignments, sensor subclassOf
PhysicalObject need to be changed to sensor subclassOf Object
time for lunch. Restart at 1.30 local time
<eparsons> Returning from Lunch - Dialling webex now !
<phila> scribe: phila
<scribe> scribeNick: phila
What topics are modules built around?
kerry: Maybe now is a good time to do the use cases discussion
SSN Use Cases & Requirements
<frans> [39]https://www.w3.org/2015/spatial/track/products/1
[39] https://www.w3.org/2015/spatial/track/products/1
frans: Yesterday we talked about the UCR with 6 open issues
... 2 remaining issues open
issue-77?
<trackbot> issue-77 -- New SSN requirement: programming/tasking
and actuation -- open
<trackbot> [40]http://www.w3.org/2015/spatial/track/issues/77
[40] http://www.w3.org/2015/spatial/track/issues/77
issue-78?
<trackbot> issue-78 -- New SSN requirement: SSN usage examples?
-- open
<trackbot> [41]http://www.w3.org/2015/spatial/track/issues/78
[41] http://www.w3.org/2015/spatial/track/issues/78
frans: These two seem not have been recorded for the new SSN
... Issue-77. I'm not in touch with the details...
phila: How can you use a vocab to program and actuation
kerry: Concept is to model the capabilities and control of a
sensing device
... It's an old SSN req that wasn't implemented but it's back
through WoT
<DanhLePhuoc> +q
kerry: I think it needs to be there
DanhLePhuoc: I roughly understand. But task/programming is
confusing.
... I think this is modelling
kerry: Tasking is on OGC word. An implementation might be,
here's an interface where you can attach code
frans: Is the programming only related to actuation?
DanhLePhuoc: You can change the rate of acquisition, etc.
... Some sensors have features you can... send some
parameters... that's what people need
... There may be serial tasks, sequences of tasks. I think
there was a task ontology some years ago.
frans: So are tasking and programming different things?
DanhLePhuoc: Tasking is more like sequencing
BartvanLeeuwen: DO we have enough knowledge and time to do
this?
kerry: It's trivial to do what's proposed in SOSA core. Whether
it's useful...
... There are certainly examples of this being done
... It's not hard, but we don't have an implementation
eparsons: So this is not currently in SSN
kerry: It was in the old requirements but never implemented
eparsons: So you'd have to come up with a way of meeting this
requirements, then you have to prove implementation within the
time we have.
kerry: Were not going to meet all the requirements, in realit.
... I think it's easy to do a simple solution.
... I think Danh will do an implementation.
... and WoT can do one I think
... I suspect this is a high priority from the SSN Group
ahaller2: Maybe you can make it more specific
... There could be a simple on/off property
frans: So this requirement will only focus on actuation.
kerry: That's fine
<DanhLePhuoc> proposal the description for Issue #77: A new
requirement for SSN is proposed: It should be possible to model
actuation functions of sensing devices.
<ahaller2> +1
<eparsons> +1
<DanhLePhuoc> +1
<jtandy> +1
<frans> +1
<Linda> +1
<BartvanLeeuwen> +1
PROPOSED: the description for Issue #77: A new requirement for
SSN is proposed: It should be possible to model actuation
functions of sensing devices
<BartvanLeeuwen> +1
RESOLUTION: the description for Issue #77: A new requirement
for SSN is proposed: It should be possible to model actuation
functions of sensing devices
ISSUE-78
<trackbot> ISSUE-78 -- New SSN requirement: SSN usage examples?
-- open
<trackbot> [42]http://www.w3.org/2015/spatial/track/issues/78
[42] http://www.w3.org/2015/spatial/track/issues/78
[43]https://www.w3.org/2015/spatial/track/issues/78
[43] https://www.w3.org/2015/spatial/track/issues/78
<DanhLePhuoc> +1
<RaulGarciaCastro> +1
<ahaller2> +1
<frans> proposal: add ssn req: There should be examples of how
the SSN ontology can be used together with other vocabularies.
<RaulGarciaCastro> +1
<Maxime> +1
<BartvanLeeuwen> +1
<frans> +1
RESOLUTION: add ssn req: There should be examples of how the
SSN ontology can be used together with other vocabularies.
<kerry> +1
<scribe> ACTION: frans to act on resolution of issues 77 and 78
[recorded in
[44]http://www.w3.org/2016/09/20-sdw-minutes.html#action01]
[44] http://www.w3.org/2016/09/20-sdw-minutes.html#action01]
<trackbot> Created ACTION-200 - Act on resolution of issues 77
and 78 [on Frans Knibbe - due 2016-09-27].
close issue-77
<trackbot> Closed issue-77.
close issue-78
<trackbot> Closed issue-78.
phila: Asks about timing of future UCR publication
frans: Couple of weeks or so
eparsons: It's going to be the final draft, at least that's the
intention
What topics are modules built around? (for real this time)
<ahaller2>
[45]https://www.w3.org/2005/Incubator/ssn/wiki/Report_Work_on_t
he_SSN_ontology
[45]
https://www.w3.org/2005/Incubator/ssn/wiki/Report_Work_on_the_SSN_ontology
kerry: What actually is a module, what goes into one
... We think we have a core and then outside that is
topic-specific modules and I want to get an understanding of
what those modules are
... Modules that are too big can be a problem
... The famous image is a modularisation that doesn't really
exist
... For me it's obvious that the deployment on the top left is
a module, some people care, others don't.
... On the right... some survival range and operating range
... There's the datasheet that says how a sensor will perform
in different environments.
... That area might be able to be hived off
maxime: Feature of interest and property can be used alone.
kerry: That's tiny
Maxime: Yes
[discussion of 'property']
phila: Probes into what modules are, why not just use what's
there? What effect will users see if you drew the boxes
differently?
[Bit of discussion]
<DanhLePhuoc> +q
phila: You can have multple docs defining terms in a single
namespace (IMHO)
Maxime: I think there's more in modularisation that drawing
boxes. If you take out DUL, you remove axioms like feature and
@@ aree disjoint
... You have an object of interest that's a fridge, and then
you want to talk about the frequency of the voltage. It is a
property of the fridge?
kerry: I'd be happy, not sure of OGC folks would be.
Maxime: It's not the properties, it's the axioms
<RaulGarciaCastro>
[46]https://www.w3.org/2015/spatial/wiki/SSN_conceptual_modules
#Overview_of_the_conceptual_modules
[46]
https://www.w3.org/2015/spatial/wiki/SSN_conceptual_modules#Overview_of_the_conceptual_modules
RaulGarciaCastro: Describes his diagram
<Maxime> +1
<DanhLePhuoc> -q
<DanhLePhuoc> +q
RaulGarciaCastro: Maybe we go through the use cases and see
which modules are needed.
<Zakim> jtandy, you wanted to ask what the downsides of not
modularising are?
jtandy: What prob;em occurs if we don't modularise. I know we
want core, O&M, etc as axioms in other modules might conflict.
I'd modularise of the governance or maintenance sections for
example are going to be different.
... but breaking it up into chunks makes sense for explanation
and usage, but I don't know the pros and cons
... If we don't split it, what do we lose.
Maxime: If we don't split, when do we know it was right.
jtandy: If an implementation only uses part of that, and
references classes they don't use, is there an extra burden?
<ahaller2> +1 great summary jtandy
jtandy: Simplicity wins. We're talking about cutting it up into
smaller pieces - why?
DanhLePhuoc: We only have 20 classes
... So we don't need to ask people to import several things,
but I think there's a separation in usage.
... If I just want to use 3, I don't see why I need to import
the other 17
kerry: So if I'm hearing this right, it would all be in the
same file, but outside that, we'd expect DULCE alignment, @@
alignment, UoM etc.
RaulGarciaCastro: We can take the decision about what is core.
kerry: There is one core.
jtandy: This morning we talked about SOSA core that doers't
have axioms beyond the simple.
... That's the first level of the Sem Web stack
... In the editors draft there's that target diagram
<ahaller2> [47]http://w3c.github.io/sdw/ssn/#Modularisation
[47] http://w3c.github.io/sdw/ssn/#Modularisation
jtandy: Is this diagram we're looking at
... I think some of the boxes in the complex diagram we see
exist in the blue box, pink box etc.
... It seems that SOSA core seems to have the simple stuff I'd
need.
... Looking at the other diagram and deciding what's in the
core...
kerry: Modulo the details...
frans: It seems that modularisation makes the diagrams smaller
... Perhaps it's possible to modularise the explanations
without modularirising the ontology.
kerry: Do we have a decision?
<RaulGarciaCastro> We will have a core module that contains a
subset of the concepts in the current SSN ontology; we don’t
plan to split the current SSN ontology into different files;
and potentially we will have modules that extend the ontology
(e.g., O&M)
<RaulGarciaCastro> The modules that extend the ontology will be
in different files
Points of agreement
- There will be a core module that is a subset of SSN
<Maxime> my understanding: core, ssn, extra, alignment X,
alignemnt Y, ...
- There will be an extension file
- there will be room to add more modules, such as O&M
<jtandy> so ... the Sensor Network Module imports the SOSA-Core
module? yes?
<Maxime> my updated understanding: core, ssn, alignment O&M,
alignemnt DUL, ... where alignements are the "extra" parts and
in the non normative parts of the doc
<Zakim> jtandy, you wanted to point out that we previously
talked about a SSN Primer as a NOTE ...
phila: AIUI - you want a 'normative' section that defines the
well implemented 'core' properties. Then there is a section on
extensions, with examples. These will not be part of the formal
standard but will introduce terms to the single namespace
... AIUI - you want a 'normative' section that defines the well
implemented 'core' properties. Then there is a section on
extensions, with examples. These will not be part of the formal
standard but will introduce new terms
'RecordOfObservation' vs 'ActivityOfObserving'
kerry: We discussed this a little in the last SSN meeting.
<ahaller2>
[48]https://www.researchgate.net/publication/305809446_Pitfalls
_in_alignment_of_observation_models_resolved_using_PROV_as_an_u
pper_ontology
[48]
https://www.researchgate.net/publication/305809446_Pitfalls_in_alignment_of_observation_models_resolved_using_PROV_as_an_upper_ontology
kerry: This potentially a big change being proposed for SSN
... The key point of the concept of an observation in SSN is
deliberately different from O&M concept. That difference is
either serious or irrelevant...
... The difference is how an observation in interpreted wrt the
act of observing
... SSN took the view that it was a record, not an action
... For many purposes it doesn't matter
... After SSN, Simon created O&M Light. He took an observation
as an event.
... It becomes an issue when SSN gets aligned with DOLCE
... We're taking DOLCE out so that's not a problem
<jtandy> when looking to align O&M and SSN with PROV-O ...
Simon says: "PROV-O provides just three base classes: Entity,
Activity and Agent. om:Observation is sub-classed from
prov:Activity, while ssn:Observation is sub-classed from
prov:Entity."
Kerry: But if you align with, say, PROV....
... Prov of data and other systems, you get access to the SSN
info as part of that provenance chain.
... This makes the observation an entity
Kerry; In DOLCE they're disjoint
scribe: In PROV an activity can be an entity
... But the O&M observation it matters
... independently, Simon did an alignment with PROV.
... When we did it, we introduced an 'Activity of Sensing'
... That can be associated with the O&M observation
... It gets ugly
[Kerry moves to the whiteboard]
-> [49]http://ceur-ws.org/Vol-1401/paper-05.pdf Sensor Data
Provenance: SSNO and PROV-O
[49] http://ceur-ws.org/Vol-1401/paper-05.pdf
Together at Last
kerry: SSN has an observation as a sub class of entity, O&M has
it as a sub class of activity
... The jump between the two you need mappings and rules -
which gets ugly.
eparsons: What if you give up on aligning them?
kerry: I can do better than that.
... Simon made a proposal to just say they're the same but I
don't think that works.
... I want to take advantage of entity and activity not being
disjoint
<Zakim> jtandy, you wanted to give my opinion when keery has
done the intro
kerry: We can just say that O&M and SSN Observation are the
same thing. That's OK in Prov. Ontologically suspect but
practical
<jtandy> I think ... For me, it seems natural to treat
Observation as an Activity ... it's something that's done at a
particular time using a specified process. It produces a some
data (the result) ... the data, an information resource, is an
Entity. SSN seems unnecessarily complex in splitting the
problem into SensorOutput, Observation and ActivityOfSensing;
OM does this in two classes: Result and Observation.
[Scribe realises I must have misunderstood what Simon said]
kerry: ActivityOfSensing doesn't exist in SSN
... It was proposed as a way of doing the alignment but it
seems overly complicated.
... I'd be happy with saying don't bother but I don't think
others would be.
... We need to take account of other people's opinions
eparsons: If it's documented what you mean...
kerry: it is
eparsons: Users can deal with the issue of they're made aware
of it. Should we have to solve it?
danbri: Is there lots of O&M data?
jtandy: Yes, It has a lot of data in OGC and ISO
... Simon has proposed an RDF representation
ahaller2: I think there's a lot of reason to align the modules
... How we do it, I'm agnostic
... We have to change the DOLCE alignment anyway
kerry: No, I don't see a reason for doing that.
... In Prov, it's OK to be an activity and an entity
ahaller2: But not DOLCE
kerry: No.
... I think there is an event class in DOLCE
... DOLCE requires them to be disjoint, Prov doesn't
<Maxime> so SSN+DUL will be incompatible with SSN+O&M, and
that's it ? if these are two different extensions, that's maybe
no big deal
[Discusses changing SSN to match O&M]
jtandy: Would you be upset if SSN Observation were a sub class
of prov:Activity
kerry: No, but why
jtandy: In O&M the definition begins with it as an event
Maxime: I care about the result of this discussion...
<Zakim> danbri, you wanted to ask about nature of SSN
deployments (e.g. is it in hardware production etc?)
danbri: SSN deployment - sounds as if O&M is well deployed.
... What's the installed base for SSN?
Kerry: It's not a standard itself.
DanhLePhuoc: There a sensor manufacturers using it, with
JSON-LD
danbri: Are there major stakeholders you could consult?
DanhLePhuoc: I know Siemens are doing this. I know one M2M
danbri: Would it make sense to identify the top users and go
and ask them?
DanhLePhuoc: There's a plugfest with Fujistu tomorrow
... I think I can collect some usage infoi
eparsons: I think you say we have two choices...
jtandy: I suggest "we're thinking of doing this, would it
disturb you?"
... I think we propose tentatively to convert ssn:Observation
to a sub class of prov:Activity, and ask at least 3 people.
... Question is, would this change cause massive problems?
kerry: And the other option is, do nothing?
DanhLePhuoc: I prefer that way.
kerry: The do nothing approach is to say that O&M and SSN
Observation are the same thing but if you use Prov then you
need to recognise that it's both Activity and Entity
PROPOSED: To either (1) align with O&M (Observation is
activity) or (2) say O&M and SSN Observation are the same thing
<danbri> is the suggestion that (SSN) Observation be refined to
treat it as a kind of action/event/activity, bringing it closer
to O&M's notion of Observation (and e.g. also prov Activity)?
PROPOSED: To either (1) align with O&M (Observation is
activity) or (2) say O&M and SSN Observation are the same thing
but leave described as they are in their own spaces
ahaller2: DOLCE has an event, it can't be an entity
<jtandy> SOSA Core currently says ...
<jtandy> sosa-core:Observation
<jtandy> rdf:type owl:Class ;
<jtandy> rdfs:comment "Activity of carrying out an
(observation) Procedure to estimate or calculate a value of a
Property of a FeatureOfInterest. Links to a Platform or Sensor
to describe what made the Observation and how; links to an
ObservableProperty to describe what the result is an estimate
of, and to a FeatureOfInterest to detail what that property was
associated with; the Result is the output."@en ;
<jtandy> rdfs:comment "An Observation carries out an
(observation) Procedure to estimate or calculate a value of a
Property of a FeatureOfInterest. Links to a Platform or Sensor
to describe what made the Observation and how; links to an
ObservableProperty to describe what the result is an estimate
of, and to a FeatureOfInterest to detail what that property was
associated with; the Result is the output."@en ;
<jtandy> rdfs:label "Observation"@en ;
<jtandy> .
[More discussion]
kerry: There would be an impact on DOLCE alignment.
<danbri> ("entity" here meaning dolce's notion of entity,
rather than something broader approximating 'thing'?)
PROPOSED: To either (1) align with O&M (Observation is
activity) or (2) say O&M and SSN Observation are the same thing
but leave described as they are in their own spaces
<Maxime> 1
<jtandy> vote : (1)
<danbri> 1
<Linda> 1
<ahaller2> 1
<DanhLePhuoc> 1
<RaulGarciaCastro> 1
<jtandy> (on behalf of Kerry = 2)
<eparsons> 1
RESOLUTION: The ssn:Observation will be redefined as an
activity, in line with O&M Observation
jtandy: Consequently, there will need to be work to realign
with DOLCE
<danbri> (do we still get this sanity-checked with top 3 SSN
stakeholders?)
<scribe> ACTION: kerry to redefine ssn:Observation and update
alignment with DOLCE [recorded in
[50]http://www.w3.org/2016/09/20-sdw-minutes.html#action02]
[50] http://www.w3.org/2016/09/20-sdw-minutes.html#action02]
<trackbot> Created ACTION-201 - Redefine ssn:observation and
update alignment with dolce [on Kerry Taylor - due 2016-09-27].
jtandy: We've just made a decision. We should make sure that
our vocab is reviewed by current users, incl, say, Siemens.
Future Face to face meetings
Discussion around WWW 2017, 3-7 April
<AZ> audio is gone
<ahaller2> trying to get you back
Meeting in December, London 12-13 December. Prob then in March
21-22 in Delft, TBC
[Coffee Break]
<eparsons> Back at 16:00
<eparsons> Thanks AZ see you so
<eparsons> NP :-)
<AZ> enjoy Lisbon
<Kerry> Introductions..
<Kerry> Chair:Kerry
<AndreaPerego> scribe: AndreaPerego
<scribe> scribeNick: AndreaPerego
<phila> scribeNick: AndreaPerego
kerry: We need to discuss about decisions that may have
implications for both groups.
DarkoAnicic: I can give a short introduction on the work done
so far.
Joint Session with WoT IG
<Kerry> Topic : web of things update
DarkoAnicic: f2f meeting will be thu - fri. You're welcome to
join.
... each f2f will have also a practical session to show what we
are doing.
... IoT means different devices, and how to connect such
devices.
... we are working also on enabling interoperability at the
application layer.
... today we have a number of standards bodies working on
different standards and platforms.
... our goal is to build a set of building blocks so that such
standards and platforms are able to use them and be
interoperable.
... in other words, we want to bridge these standards and
platforms.
... (responding to kerry) we don't want to provide different
solutions for each of these standards / tools, but to set up
re-usable and sharable building blocks.
... (describing the building blocks) building blocks include:
application script layer (interoperability of scripts across
devices), resource model (abstraction of properties and actions
for devices), protocol bindings.
... Notion of "thing description" plays a central role in the
framework.
<DarkoAnicic> TD current practices:
[51]http://w3c.github.io/wot/current-practices/wot-practices.ht
ml#thing-description
[51] http://w3c.github.io/wot/current-practices/
DarkoAnicic: Why we need it? This is needed to know what kind
of data you serve, who you are, how you can access
data/function, what kind of functions are available, protocols,
encodings, which are the security constraints (if any).
... The thing description describes the resource model, the
protocol bindings, and the WoT servient (client/server role).
... This allows also to avoid all the work around embedded
programming.
... Thing descriptions include descriptive metadata,
security-related info (e.g., security token), supported
protocols and data formats.
... Thing descriptions are provided in JSON-LD.
... The JSON-LD context mechanism allows to provide also
contextual information that is important for operating the
device.
... Also JSON binary formats exist.
... (describing JSON-LD snippet).
victor: About the ontology, this includes two different
contexts, one defined by [missed it] and one that can be used
in order to define your own context.
frans: Do you have predefined contexts people can use?
victor: Yes.
DarkoAnicic: Information like UoM can be imported from other
contexts as well.
frans: Have you also location information?
DarkoAnicic: Not really, but you can extend it with location
information, by reusing an existing vocabulary.
... One part of the work is devoted to discovery.
... In the future we'll have events where you can bring your
own vocabulary (e.g., location), and we'll play with them
(e.g., to find devices in a given location).
Kerry: Are you then agnostic wrt the vocabularies used?
DarkoAnicic: Yes, we have a vocabulary that needs to be used
for making things work, but then you can add other
vocabularies.
Maxime: Are in this way limiting the extensibility of the thing
description?
... I have some concerns about the fact that the thing
description denotes both the representation and the
presentation of the "thing".
<ahaller2> +1 to maxime's concern
DarkoAnicic: A component of the architecture includes a thing
description repository, meant to register and discover things
descriptions (TDs).
... You can extend TDs with other semantic models.
... This can be done for infos concerning application models,
domain-dependent models, domain-independent models.
Maxime: About UoM there are different vocabularies that may be
incompatible. How you solve these possible conflicts?
DarkoAnicic: We don't have a solution - this is a normal
problem with standards.
... So, it's out of scope of our WG.
danbri: What about specific domains (e.g., agriculture)? Can
you deal with them?
DarkoAnicic: No, this is not in the WG scope - we don't define
domain-specific properties. We focus on the TD, that is
domain-independent.
sebastian: The TD is like the index.html page of a Web site.
It's an entry point to know what the device can provide.
Kerry: Is there any protocol to negotiate the change of
context?
... How you can find out who can speak that language?
<danbri> (agriculture for example,
[52]http://agroportal.lirmm.fr/
[53]http://www.agrisemantics.org/ … are very relevant to WoT
apps but are not presented as IoT/WoT initiatives; it is good
that that Thing Description architecture seems open-ended for
such things to be included.
[52] http://agroportal.lirmm.fr/
[53] http://www.agrisemantics.org/
<danbri> )
DarkoAnicic: You can, e.g., import SSN, then the other thing
discover yours, and then it has to fetch the context to know
about SSN.
... The discovery can be done also on the additional
vocabularies that have been used.
victor: There's a proposal for an WoT ontology based on DUL.
... there's an alignment problem that should be solved by SSN
[missed which is that]
Kerry: We can standardise the WoT ontology in the work on SSN.
<DanhLePhuoc_> +q
<Kerry> Wot should be standalone
Kerry: Do you consider alignments to be your task, or rather
this should be done by other communities?
victor: The idea is this should be done by communities using
these "things".
Kerry: This may be an opportunity to optimise the alignments
planned in SSN.
<DanhLePhuoc_> +q
RaulGarciaCastro: SSN is not covering the digital
representation of the "thing" (i.e., the TD).
<Maxime> major difference: ssn:Device is a physical thing,
whereas wot2:Thing would be its digital mirror
DarkoAnicic: We can also use alignments in schema.org.
<sebastian> we consider both, a wot2:Thing can be physical or
virtual
danbri: The problem is that this is covering too many domains.
DanhLePhuoc_: (showing a discovery example)
victor: This shows the use of one of the discovery APIs - in
this case a SPARQL endpoint.
<danbri> …. it passes in a basic sparql-based pattern (as an
example at least)
<Kerry> +
ahaller2: Coming back to SSN, we may need to link back to your
TD, or vice versa.
DarkoAnicic: Yes, and you can use also a generic property ("has
description").
sebastian: Which can be the scenario for this?
ahaller2: To show which is the origin of the observations.
<DanhLePhuoc_> +q
ahaller2: And maybe to know how to access the sensor.
DanhLePhuoc_: May be worth knowing a bit the agenda and the
timing for your work, so we can try to align our efforts.
DarkoAnicic: WoT to be a WG in october, and 1st f2f end of this
year / beginning of next year.
sebastian: We have 3-4 f2f meetings every year.
DarkoAnicic: The next f2f is very likely to be in the US. But
we can arrange a "plug fest" where anyone can participate.
Maxime: May be worth checking if SSN and WoT are talking the
same language - this would help better understand what needs to
be done.
AndreaPerego: About the property to link observations and TDs,
this may already exist, e.g., in PROV-O.
Kerry: Yes, but if we define one in SSN this would be
"stronger".
Summary of Action Items
[NEW] ACTION: frans to act on resolution of issues 77 and 78
[recorded in
[54]http://www.w3.org/2016/09/20-sdw-minutes.html#action01]
[NEW] ACTION: kerry to redefine ssn:Observation and update
alignment with DOLCE [recorded in
[55]http://www.w3.org/2016/09/20-sdw-minutes.html#action02]
[54] http://www.w3.org/2016/09/20-sdw-minutes.html#action01
[55] http://www.w3.org/2016/09/20-sdw-minutes.html#action02
Summary of Resolutions
1. [56]the description for Issue #77: A new requirement for
SSN is proposed: It should be possible to model actuation
functions of sensing devices
2. [57]add ssn req: There should be examples of how the SSN
ontology can be used together with other vocabularies.
3. [58]The ssn:Observation will be redefined as an activity,
in line with O&M Observation
jtandy: Consequently, there will need to be work to realign
with DOLCE
<danbri> (do we still get this sanity-checked with top 3
SSN stakeholders?)
<scribe> ACTION: kerry to redefine ssn:Observation and
update alignment with DOLCE [recorded in
[59]http://www.w3.org/2016/09/20-sdw-minutes.html#action02]
<trackbot> Created ACTION-201 - Redefine ssn:observation
and update alignment with dolce [on Kerry Taylor - due
2016-09-27].
jtandy: We've just made a decision. We should make sure
that our vocab is reviewed by current users, incl, say,
Siemens.
Future Face to face meetings
Discussion around WWW 2017, 3-7 April
<AZ> audio is gone
<ahaller2> trying to get you back
Meeting in December, London 12-13 December. Prob then in
March 21-22 in Delft, TBC
[Coffee Break]
<eparsons> Back at 16:00
<eparsons> Thanks AZ see you so
<eparsons> NP :-)
<AZ> enjoy Lisbon
<Kerry> Introductions..
<Kerry> Chair:Kerry
<AndreaPerego> scribe: AndreaPerego
<scribe> scribeNick: AndreaPerego
<phila> scribeNick: AndreaPerego
kerry: We need to discuss about decisions that may have
implications for both groups.
DarkoAnicic: I can give a short introduction on the work
done so far.
Joint Session with WoT IG
<Kerry> Topic : web of things update
DarkoAnicic: f2f meeting will be thu - fri. You're welcome
to join.
... each f2f will have also a practical session to show
what we are doing.
... IoT means different devices, and how to connect such
devices.
... we are working also on enabling interoperability at the
application layer.
... today we have a number of standards bodies working on
different standards and platforms.
... our goal is to build a set of building blocks so that
such standards and platforms are able to use them and be
interoperable.
... in other words, we want to bridge these standards and
platforms.
... (responding to kerry) we don't want to provide
different solutions for each of these standards / tools,
but to set up re-usable and sharable building blocks.
... (describing the building blocks) building blocks
include: application script layer (interoperability of
scripts across devices), resource model (abstraction of
properties and actions for devices), protocol bindings.
... Notion of "thing description" plays a central role in
the framework.
<DarkoAnicic> TD current practices:
[60]http://w3c.github.io/wot/current-practices/wot-practice
s.html#thing-description
DarkoAnicic: Why we need it? This is needed to know what
kind of data you serve, who you are, how you can access
data/function, what kind of functions are available,
protocols, encodings, which are the security constraints
(if any).
... The thing description describes the resource model, the
protocol bindings, and the WoT servient (client/server
role).
... This allows also to avoid all the work around embedded
programming.
... Thing descriptions include descriptive metadata,
security-related info (e.g., security token), supported
protocols and data formats.
... Thing descriptions are provided in JSON-LD.
... The JSON-LD context mechanism allows to provide also
contextual information that is important for operating the
device.
... Also JSON binary formats exist.
... (describing JSON-LD snippet).
victor: About the ontology, this includes two different
contexts, one defined by [missed it] and one that can be
used in order to define your own context.
frans: Do you have predefined contexts people can use?
victor: Yes.
DarkoAnicic: Information like UoM can be imported from
other contexts as well.
frans: Have you also location information?
DarkoAnicic: Not really, but you can extend it with
location information, by reusing an existing vocabulary.
... One part of the work is devoted to discovery.
... In the future we'll have events where you can bring
your own vocabulary (e.g., location), and we'll play with
them (e.g., to find devices in a given location).
Kerry: Are you then agnostic wrt the vocabularies used?
DarkoAnicic: Yes, we have a vocabulary that needs to be
used for making things work, but then you can add other
vocabularies.
Maxime: Are in this way limiting the extensibility of the
thing description?
... I have some concerns about the fact that the thing
description denotes both the representation and the
presentation of the "thing".
<ahaller2> +1 to maxime's concern
DarkoAnicic: A component of the architecture includes a
thing description repository, meant to register and
discover things descriptions (TDs).
... You can extend TDs with other semantic models.
... This can be done for infos concerning application
models, domain-dependent models, domain-independent models.
Maxime: About UoM there are different vocabularies that may
be incompatible. How you solve these possible conflicts?
DarkoAnicic: We don't have a solution - this is a normal
problem with standards.
... So, it's out of scope of our WG.
danbri: What about specific domains (e.g., agriculture)?
Can you deal with them?
DarkoAnicic: No, this is not in the WG scope - we don't
define domain-specific properties. We focus on the TD, that
is domain-independent.
sebastian: The TD is like the index.html page of a Web
site. It's an entry point to know what the device can
provide.
Kerry: Is there any protocol to negotiate the change of
context?
... How you can find out who can speak that language?
<danbri> (agriculture for example,
[61]http://agroportal.lirmm.fr/
[62]http://www.agrisemantics.org/ … are very relevant to
WoT apps but are not presented as IoT/WoT initiatives; it
is good that that Thing Description architecture seems
open-ended for such things to be included.
<danbri> )
DarkoAnicic: You can, e.g., import SSN, then the other
thing discover yours, and then it has to fetch the context
to know about SSN.
... The discovery can be done also on the additional
vocabularies that have been used.
victor: There's a proposal for an WoT ontology based on
DUL.
... there's an alignment problem that should be solved by
SSN [missed which is that]
Kerry: We can standardise the WoT ontology in the work on
SSN.
<DanhLePhuoc_> +q
<Kerry> Wot should be standalone
Kerry: Do you consider alignments to be your task, or
rather this should be done by other communities?
victor: The idea is this should be done by communities
using these "things".
Kerry: This may be an opportunity to optimise the
alignments planned in SSN.
<DanhLePhuoc_> +q
RaulGarciaCastro: SSN is not covering the digital
representation of the "thing" (i.e., the TD).
<Maxime> major difference: ssn:Device is a physical thing,
whereas wot2:Thing would be its digital mirror
DarkoAnicic: We can also use alignments in schema.org.
<sebastian> we consider both, a wot2:Thing can be physical
or virtual
danbri: The problem is that this is covering too many
domains.
DanhLePhuoc_: (showing a discovery example)
victor: This shows the use of one of the discovery APIs -
in this case a SPARQL endpoint.
<danbri> …. it passes in a basic sparql-based pattern (as
an example at least)
<Kerry> +
ahaller2: Coming back to SSN, we may need to link back to
your TD, or vice versa.
DarkoAnicic: Yes, and you can use also a generic property
("has description").
sebastian: Which can be the scenario for this?
ahaller2: To show which is the origin of the observations.
<DanhLePhuoc_> +q
ahaller2: And maybe to know how to access the sensor.
DanhLePhuoc_: May be worth knowing a bit the agenda and the
timing for your work, so we can try to align our efforts.
DarkoAnicic: WoT to be a WG in october, and 1st f2f end of
this year / beginning of next year.
sebastian: We have 3-4 f2f meetings every year.
DarkoAnicic: The next f2f is very likely to be in the US.
But we can arrange a "plug fest" where anyone can
participate.
Maxime: May be worth checking if SSN and WoT are talking
the same language - this would help better understand what
needs to be done.
AndreaPerego: About the property to link observations and
TDs, this may already exist, e.g., in PROV-O.
Kerry: Yes, but if we define one in SSN this would be
"stronger".
DarkoAnicic: You're also very welcome to join our meetings
here at TPAC, also to send a message to the WG.
Kerry: (describing the re-design of SSN)
... (going through the source in GH).
<Maxime> [63]http://ci.emse.fr/pep/
<Maxime> SOSA-Core
[64]https://raw.githubusercontent.com/w3c/sdw/kjanowicz-ssn
/ssn/rdf/sosa.ttl
WoT IG wiki: [65]https://www.w3.org/WoT/IG/wiki
<frans> ACTION: kerry to propose a property in SSN to link
to WoT TD [recorded in
[66]http://www.w3.org/2016/09/20-sdw-minutes.html#action03]
<trackbot> Created ACTION-202 - Propose a property in ssn
to link to wot td [on Kerry Taylor - due 2016-09-27].
<frans> ACTION: Kerry to make an agenda item to analyze the
difference between TD between SSN [recorded in
[67]http://www.w3.org/2016/09/20-sdw-minutes.html#action04]
<trackbot> Created ACTION-203 - Make an agenda item to
analyze the difference between td between ssn [on Kerry
Taylor - due 2016-09-27].
<frans> ACTION: Kerry to plan to use WoT plugfests to do
SSN implementation [recorded in
[68]http://www.w3.org/2016/09/20-sdw-minutes.html#action05]
<trackbot> Created ACTION-204 - Plan to use wot plugfests
to do ssn implementation [on Kerry Taylor - due
2016-09-27].
meeting closes
Summary of Action Items [NEW] ACTION: frans to act on
resolution of issues 77 and 78 [recorded in
[69]http://www.w3.org/2016/09/20-sdw-minutes.html#action01]
[NEW] ACTION: Kerry to make an agenda item to analyze the
difference between TD between SSN [recorded in
[70]http://www.w3.org/2016/09/20-sdw-minutes.html#action04]
[NEW] ACTION: Kerry to plan to use WoT plugfests to do SSN
implementation [recorded in
[71]http://www.w3.org/2016/09/20-sdw-minutes.html#action05]
[NEW] ACTION: kerry to propose a property in SSN to link to
WoT TD [recorded in
[72]http://www.w3.org/2016/09/20-sdw-minutes.html#action03]
[NEW] ACTION: kerry to redefine ssn:Observation and update
alignment with DOLCE [recorded in
[73]http://www.w3.org/2016/09/20-sdw-minutes.html#action02]
[59] http://www.w3.org/2016/09/20-sdw-minutes.html#action02]
[60] http://w3c.github.io/wot/current-practices/
[61] http://agroportal.lirmm.fr/
[62] http://www.agrisemantics.org/
[63] http://ci.emse.fr/pep/
[64]
https://raw.githubusercontent.com/w3c/sdw/kjanowicz-ssn/ssn/rdf/sosa.ttl
[65] https://www.w3.org/WoT/IG/wiki
[66] http://www.w3.org/2016/09/20-sdw-minutes.html#action03]
[67] http://www.w3.org/2016/09/20-sdw-minutes.html#action04]
[68] http://www.w3.org/2016/09/20-sdw-minutes.html#action05]
[69] http://www.w3.org/2016/09/20-sdw-minutes.html#action01
[70] http://www.w3.org/2016/09/20-sdw-minutes.html#action04
[71] http://www.w3.org/2016/09/20-sdw-minutes.html#action05
[72] http://www.w3.org/2016/09/20-sdw-minutes.html#action03
[73] http://www.w3.org/2016/09/20-sdw-minutes.html#action02
Summary of Resolutions
1. [74]the description for Issue #77: A new requirement for
SSN is proposed: It should be possible to model actuation
functions of sensing devices
2. [75]add ssn req: There should be examples of how the SSN
ontology can be used together with other vocabularies.
3. [76]The ssn:Observation will be redefined as an activity,
in line with O&M Observation
[End of minutes]
__________________________________________________________
Received on Wednesday, 21 September 2016 07:59:11 UTC