Spatial Data on the Web WG F2F, TPAC 2016 Day 2

<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_> http://w3c.github.io/sdw/eo-qb/

<billrobe_> https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Coverages

<billrobe_> 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> 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_> http://w3c.github.io/sdw/eo-qb/

Bill: the doc at this link will become a w3c note

<billrobe_> 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_> http://w3c.github.io/sdw/coverage-json/

Bill: this will also be a W3C note and OGC discussion paper

<billrobe_> 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_> https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED.owl

dmitrybrizhinev: using rdf to say things about your data

<billrobe_> 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> 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_> 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: https://anulinkedearth.org/landsat/query?query=PREFIX+xsd:+%3Chttp:%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23%3E%0APREFIX+led:+%3Chttp:%2F%2Fwww.example.org%2FANU-LED%23%3E%0APREFIX+geo:+%3Chttp:%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%0APREFIX+qb:++%3Chttp:%2F%2Fpurl.org%2Flinked-data%2Fcube%23%3ESELECT+%3Fsubject+%3FgeoSparql+%3FtimePeriod+%3Fband+%3Fvalue+%3Fresolution+%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_> 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: 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_> 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_> 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 <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: 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_> 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> 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> 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> 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 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> 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> http://www.w3.org/2015/spatial/track/issues/77

issue-78?

<trackbot> issue-78 -- New SSN requirement: SSN usage examples? -- open

<trackbot> 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> http://www.w3.org/2015/spatial/track/issues/78

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 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> 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> 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> 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> 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]

-> http://ceur-ws.org/Vol-1401/paper-05.pdf Sensor Data Provenance: SSNO and PROV-O

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 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: http://w3c.github.io/wot/current-practices/wot-practices.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, http://agroportal.lirmm.fr/ 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".