– DRAFT –
(MEETING TITLE)

mm: (gives background)
… WoT wrapping up the spec work
… remaining issues on how to handle geospatial data (for the next version specs)
… did quick survey on OGC specs

ss: first step should be identifying smaller topics
… describing geometory, etc.

mm: also wanted to say we're also breaking up things into smaller pieces
… and working on use cases
… e.g., rooms within a building
… may need to involve multiple organizations

jt: Scott, you mentioned smaller topics
… ontology/vocabulary we use
… also new OGC API specs

ss: kind of ubiquitous

mm: connections and relationships with the other standards is important

jt: Rob?

rs: yes, had a quick look at WoT
… pretty much overlap with our work
… we're defining OGC standards
… including GeoPose
… video map tracks
… synchronizing time meta data and geospatial data
… also Geo Aligning by Immersive Web group as well
… orientation accuracy
… filling in the gaps

mm: have reviewed Geo Pose
… solves narrow problems
… viewpoint and origin
… but doesn't handle accuracy
… talking about a use case including velocity of robots
… felt that large number of narrow standards
… unified modular approach
… also tagging data
… leverage of using RDF
… annotate the data

cp: clarification for Michael's point
… use cases include several groups
… (some of them are) not driven by AR
… our thinking was other standard would have Geo Pose to express velocity
… 8 standards all about time
… velocity is about place and time

mm: velocity is a vector of point
… changing the position

kaz: would suggest we split the discussion points
… e.g., vocabulary, data model and API
… think "velocity" is pat of vocabulary

mm: right
… let's once go back to there
… our issue is metadata for discovery
… relates to query language
… also maybe around time-series data
… our question is encoding of the data
… Geo Pose does define something close to our points

jt: most interesting thing
… encoding geolocation data
… location, velocity, position, etc.

mm: our serialization is JSON-LD
… different systems may have different mechanism to handle the data

jt: how close are they being able to provide semantic presentation?

rs: Geo Pose is a container
… location/position and orientation
… you can choose encoding as you like
… data model rather than a specific syntax

mm: technically, WoT TD is something like that

mm: defining RDF for Geo Pose would not be difficult
… want to look at modular systems

jt: here a bunch of properties and would like to add some more

mm: would like to specify @context on geolocation data for the WoT Thing Description
… standardized vocabulary using RDF
… to be applied to WoT Discovery

jt: what the vocabulary you need?
… what kind of discovery is needed?
… recently, had an OGC meeting last week
… RDF world and the OGC world
… interesting to revisit
… OGC world to be linked via RDF

mm: right
… would be fine if we could refer to that data from WoT TD

jt: anybody familiar with Geo SPARQL?
… there is an ontology about whole bunch of things
… includes RDF implementations

mm: should look into it more
… searching WoT TD
… we could use Geo SPARQL to get geolocation data
… would be my homework

jt: ok
… on top of the existing ontology, standardize properly
… can point you to afterwards

mm: also we're discussing I18N
… various types of time expressions

cl: hard work on time
… abstract model on time
… ISO for last 40 years
… would take a simpler model
… atomic time, UNIX time, etc.
… established a group with ISO 19
… geographical time coding
… also ISO 8601
… 2 different things

mm: need to come with some consensus
… would be nice to have one specific notation

cl: starting to get two things
… if you want to have date/time, etc., that's ok
… and if you don't, can have UNIX time, etc.
… OGC people have not moved to ontology world yet

mm: if know the definition in standardized manner
… that's great
… what's the data for devices is our question

rs: Geo Pose can handle location and orientation
… dynamic aspect of that
… has specific API for query
… probably those two are the key elements
… want to know what time is being looked at
… the areas we're looking at are quite overlapped

mm: orthogonal thinking of data and device
… geolocation is part of that
… also defining internal data within a device
… separate deliverable from the WoT spec
… can generalize your approach?

rs: looking from an opposite angle
… it's just one big data space to be generalized

mm: yeah
… have to go back and look into Geo Pose carefully
… and query language
… wondering about network APIs
… our priority is network APIs

rs: yeah
… had a breakout session during TPAC

mm: average, min, max
… can be a query if you support time data
… radius at some point too
… would see some unified style
… may also need a bit broader search
… e.g., world-wide search on the Web

jt: there is a queue
… I'm first

<jtandy> https://www.w3.org/TR/sdw-bp/

jt: have you read the Spatial data Best Practice document?

mm: not every detail yet

jt: ok
… how to handle geospatial data is described there
… should be a reasonable starting point

cl: one of the APIs is EDR retrieval api
… a bit misleading name
… data retrieval is done

<jtandy> (environmental data retrieval)

mm: certainly inline

<McCool> https://www.ogc.org/standards/ogcapi-edr

<McCool> there is also this for BIM: https://brickschema.org/ontology/

kaz: would propose a breakout session during TPAC 2022 again after our reading the specs again

mm: SDWWG will not meet

kaz: maybe a hybrid session then?

jt: TPAC is 3 months away

<McCool> https://www.w3.org/TR/owl-time/

jt: we need to have info share
… if you can write down something about what you want to use
… RDF vocabulary, serialization, etc.
… would use this vocab and that, etc.
… how would that sound?

mm: yeah
… need to collect relevant resources
… but would agree it would be nice
… concrete proposal would be useful

jt: given the scope of the information you would encode
… and geo folks on our side to see that

mm: a couple of steps there
… use cases drive requirements
… then examples
… strawman proposal on vocabulary
… also survey of existing standards
… EDR, etc.

jt: information needed to be encoded
… do you think you could build an example?
… we can connect your points to the existing standards

mm: good starting point
… but also think about another problem about metadata
… overall mechanism to handle updates for locations

kaz: ok
… let's think about the first step then

mm: look into existing standards again
… generate a concrete example
… in July, we can schedule the next meeting

jt: ok
… in terms of what we talked about
… revising your example

<McCool> https://github.com/w3c/wot-discovery/blob/main/proposals/geolocation.md

mm: there are bunch of examples within our use cases
… would be a starting point

jt: ok
… how long would it take?

mm: let's say one month from now

jt: we'll have the next plenary call in 4 weeks

mm: sounds good
… FYI, we'll talk about the next Charter during TPAC
… 10-20 min presentation during the next SDW call
… can get feedback offline later on GitHub as well
… would update our next Charter based on the discussion

jt: we want to nail down the gaps

kaz: next call on July 28?

jt: July 21

mm: at this time?

jt: yes

[adjourned]