- From: Francois Daoust <fd@w3.org>
- Date: Fri, 24 Feb 2017 10:54:15 +0100
- To: <public-sdw-wg@w3.org>
Hi all,
The draft minutes of Wednesday's plenary call are available at:
http://www.w3.org/2017/02/22-sdw-minutes.html
... and copied as raw text below.
Thanks,
Francois.
-----
Spatial Data on the Web Working Group Teleconference
22 Feb 2017
[2]Agenda
[2] https://www.w3.org/2015/spatial/wiki/Meetings:Telecon201700222
See also: [3]IRC log
[3] http://www.w3.org/2017/02/22-sdw-irc
Attendees
Present
eparsons, kerry, mlefranc, SimonCox, ahaller2, LarsG,
KJanowic, jtandy, Linda, RaulGarciaCastro, ByronCinNZ,
MattPerry, AndreaPerego, roba, DanhLePhuoc_
Regrets
Phila, Scott, Bill
Chair
eparsons
Scribe
Jeremy Tandy
Contents
* [4]Topics
1. [5]Approve last week's minutes
2. [6]Patent Call
3. [7]Namespace for SOSA and SSN ontology
* [8]Summary of Resolutions
__________________________________________________________
Approve last week's minutes
<eparsons> [9]https://www.w3.org/2017/02/08-sdw-minutes
[9] https://www.w3.org/2017/02/08-sdw-minutes
<eparsons> +1
<Linda> +1
+1
<RaulGarciaCastro> +1
<AndreaPerego> +1
<kerry> +1
<mlefranc> +1
RESOLUTION: Approve last week's minutes
Patent Call
<roba> +1
<eparsons> [10]https://www.w3.org/2015/spatial/wiki/Patent_Call
[10] https://www.w3.org/2015/spatial/wiki/Patent_Call
eparsons: calls out the patent stuff ...
... we'll miss this!
Namespace for SOSA and SSN ontology
eparsons: main topic is from the SSN subgroup
... invites Armin to introduce the subject
<mlefranc> see the wiki page:
[11]https://www.w3.org/2015/spatial/wiki/NamespaceIssue
[11] https://www.w3.org/2015/spatial/wiki/NamespaceIssue
<ahaller2> [12]http://w3c.github.io/sdw/ssn/#Modularization
[12] http://w3c.github.io/sdw/ssn/#Modularization
ahaller2: biggest issue is how we integrate SOSA and SSN
... SOSA is a small lightweight ontology
... SSN imports this
... both live in separate documents
<ahaller2>
[13]https://www.w3.org/2015/spatial/wiki/NamespaceIssue#Three_o
ptions_in_a_nushell
[13] https://www.w3.org/2015/spatial/wiki/NamespaceIssue#Three_options_in_a_nushell
ahaller2: question is whether we should have one or two
namespaces
<KJanowic> two URIs and two files
ahaller2: see wiki page link
... example, see Platform
... Platform is defined in the core
... [but also in SSN]
... currently we have set things up with two namespaces [didn't
catch what these are]
<KJanowic> [14]http://www.w3.org/ns/ssn/ for SSN and
[15]http://www.w3.org/ns/sosa/ for SOSA
[14] http://www.w3.org/ns/ssn/
[15] http://www.w3.org/ns/sosa/
ahaller2: the two namespaces mean that we have, for example,
sosa:Platform
... there are options about how SSN might narrow this
definition
... the subject we discuss today is [...]
... [...] if we have one unified namespace, we need to decide
which namespace that is
... options are summarised in the wiki page
... mechanics of each option are described in the wiki page
<KJanowic> discussion is on whether to have either one
namespace for ssn and sosa or two namespaces, one for sosa and
one for ssn.
ahaller2: e.g. how each of the options resolves to find the
right definition
eparsons: let's avoid jumping into the details
<KJanowic> +1 to broader discussion first
eparsons: let's focus on the broader discussion
... going to the queue
mlefranc: tries to explain the main issues on a higher level
... first of all, technically it's possible to have one or two
namespace
... the question was raised during F2F Lisbon; this issue is
now resolved
... the main issue for me is that some namespaces are defined
in one namespace, some in the other
... this is a burden for the user
... [examples given]
... this is the real problem for end users to learn what goes
where
KJanowic: reflects on discussion
... clarifies that this issue only occurs if you use the
[extension mechanism?]
... SOSA is a lightweight ontology
... SSN provides "more commitment"
... how do we use these ontologies together
Linda: can we clarify what the benefits of each approach are?
ahaller2: using one or two namespaces
... there is very little difference between the options
... advantage of one namespace
[I think ahaller2 talks about terms only appearing in one
namespace]
<KJanowic> and this is a very important point
ahaller2: the only difference between one and two namespaces if
we avoid reusing terms across the two namespaces is how the
individual ontology files are set up
<KJanowic> what we would be doing with one namespace is not
what is the typical solution we see on the web and this is
really important for a group like ours (and end users)
eparsons: can we focus on the perspective of the user here; the
advantage of one or two namespaces?
mlefranc: emphasises the problem of using two namespaces, a
developer might not know what prefix to use
... there are also other technical requirements
... 1/ the naming or branding
... folks really like SOSA [?] because they like to talk about
actuators
<KJanowic> I have to disagree here
mlefranc: from the two sides perspective, we want to avoid
duplicating the terms, e.g. sosa:Platform and ssn:Platform
<SimonCox> jtandy: and samples
KJanowic: again we mix many things
... 1/ namespaces
... 2/ whether we extend / sub-class sosa terms
... agrees with ahaller2
... this is what is done on the web
... common practice is one namespace, one URI, one document
... a standard is not the right place to conduct an experiment
about publishing ontologies
<KJanowic> but we have two ontologies, we agreed on that before
(two URIs, two files)
kerry: the thing about having one namespace, is that we will be
perceived to have one ontology
... in practice, as a new user, you'll only see the simple
terms from SOSA
<KJanowic> think about prefix.cc , this will clearly make a
difference
kerry: only if you are [looking at more detailed cases] will
you end up resolving to the more [axiomatic?] definitions in
SSN
... what you see is usage dependent
<KJanowic> sosa instances are not automatically ssn instances
kerry: only if you use the term from the more complex SSN would
you [see any different behaviour]
... this is a very elegant solution to publish modular
ontologies
... cites PROV-O which is modularised, but only as far as the
documentation
... the machinery used to publish PROV-O doesn't really support
this
... if we end up with sosa: Platform and ssn:Platform, this is
a major failure
SimonCox: a couple of comments
1/ a little concerned about where kerry finished the discussion
scribe: sosa:Platform and ssn:Platform is unlikely
<KJanowic> same here
SimonCox: 2/ we need to be clear about our user audience
... earlier eparsons talked about linked data professionals
... and mlefranc talked about confusion of using multiple
namespaces
<mlefranc> ... in the same REC
SimonCox: linked data professionals are evidently comfortable
in using multiple namespaces
... our main audience for SOSA core is the web developer, much
less concerned about linked data professionals
ahaller2: as a lightweight user, you'll only ever know about
SOSA
... also, we're not deciding [...]
... if you have two namespaces, you don't know which to use
... because you don't know which one System is defined in
<KJanowic> [16]http://prefix.cc/
[16] http://prefix.cc/
ahaller2: we would need to define some mechanism to redirect
folks to the right namespace even if the users choose the wrong
one
KJanowic: look at prefix.cc for how people look up ontologies
... this is the common way
... one namespace
... we need to keep to the common pattern
roba
roba: [tries to clarify]
... there are two issues being conflated
<KJanowic> two namespaces is the common way, one namespace is
not. also prefix.cc would work with two but not with one
namespace
roba: 1/ simple behaviour: content negotiation to get the OWL
version if you want the detailed axioms
<laurent_oz> Some factors which may help to make a decision:
... will we there eventually be a schema.org extension
"reproducing" SOSA? ... do we want only 1/2 of what we do to be
ported into it or everything ... risk of confusion around the
difference in modelling style: lightweight or axiomatic? ...
maybe can be solved by providing JSON-LD versions (small
snippets which matches Jano's requirement to be small) which is
lightweight and an OWL/TTL version bein[CUT]
roba: 2/ the other issue is [missed - sorry]
<roba> yes - its a constraint that SSN must restate SOSA
semantics using OWL - not change meaning
mlefranc: suggests that we can't use content negotiation to
serve different information [SOSA and SSN definitions are
different]
<ChrisLittle> Preseent+ ChrisLittle
mlefranc: responding to KJanowic, this pattern is not new
<KJanowic> yes, in your research project but not widely.
mlefranc: example cited [missed]
... last thing, I see the focus is on SOSA, and feel that the
SSN is disregarded,
<KJanowic> no, this is a misunderstanding. I am very commited
to SSN. I am one of the developers.
<roba> Two issues: same terms, SOSA, but SSN provides formal
axiomitastion = a different representation - and can therefoire
use content-negotiation to get OWL (SSN)
mlefranc: the Charter says that we should result in something
that is fully backward compatible
... worries that SOSA and SSN will become disjoint products
<roba> the other issue is whther SSN ontology introduces new
terms - and hence the discussion is really what namespace these
should be in
eparsons: closes the queue [and attempts to summarise]
<kerry> +1
<RaulGarciaCastro> +1
<KJanowic> -1
<mlefranc> +1
eparsons: how many people think there should be just one
namespace?
<Linda> -1
<ahaller2> 0
<laurent_oz> +1
<SimonCox> 0
<ChrisLittle> 0
0
<MattPerry> -1
<LarsG> -1
<AndreaPerego> 0
<roba> in all cases , SSN will be 100% consistent with SOSA
<roba> -1
[+1 = one namespace]
eparsons: hmmm, that's pretty much split
<KJanowic> 4x +1, 5x -1
eparsons: queue is open again, but only to focus on this
specific issue
<SimonCox> if 0's are = -1 as Ed asked, then it is mostly
against
SimonCox: what does zero mean?
... people have said "-1"
eparsons: zero and -1 are against "one namespace"
SimonCox: so that's 10 against, 4 for
<ChrisLittle> My zero was abstain
<AndreaPerego> Mine as well - undecided. Sorry.
<SimonCox> SOrry for barging in - seemed like a process problem
there.
KJanowic: if you are a user of prefix.cc then the one namespace
wouldn't work
... we need to manage expectations here
roba: 2 issues
<laurent_oz> Disadvantage of two namespaces: not reaching out
to new users for parts of SSN which are deemed too heavy
roba: 1/ does SSN add axioms to terms defined in the SOSA
namespace
<KJanowic> kjanowic: two namespaces: expectation handling --->
this is what all others do. second: to the best of my
understanding platforms like prefix.cc would not work well with
one namespace
<KJanowic> new terms go into ssn
roba: 2/ are new terms defined for SSN included in the SOSA
namespace
... these are separate concerns
<laurent_oz> Disadvantage of two namespaces: what happens to
sosa (and to ssn) if there is a schema.org extension
reproducing SOSA-only, or SOSA + SSN?
<Linda> Rob's 2 is the 'one namespace' solution right?
eparsons: let's look at having just one namespace instead of
two
<SimonCox> roba: I agree - that interpretation underpinned
Kerry's assumption (which was reasonable, but not the only
option)
eparsons: from a layman's perspective, it appears to be simpler
to have just one.
... what is the advantage of two
<roba> two for what - addiung new terms or adding (consistent)
axioms?
kerry: the only advantage for having two, is that if you use a
term that is defined in the simple ontology, then you get that
one
... if you ask for one from the complex ontology, you get that
<laurent_oz> Advantage of having one namespace: will force the
group to do more work to build a consistent result
kerry: issue is that if you ask for the wrong one (using the
wrong namespace prefix) then you get the wrong definition
... also, I've seen this work in prefix.cc
<RaulGarciaCastro> +1 to that
<roba> Can we vote first to use one namespace for terms covered
in SOSA, adding more axioms in SSN that are consistent with
SOSA text definitions - and then vote on what to do with new
terms
mlefranc: [...] if we have terms in one namespace, there's no
confusion,
<ahaller2> roba's proposal for a vote sounds reasonable to
untangle the issue
<roba> documentation can point to SSN - if you search for
platform in OWL representation you get SSN...
mlefranc: but if we have new terms only defined in SSN, [...]
KJanowic: we do have two ontologies
... SOSA and SSN which imports SOSA
... let's say we have one namespace
... where would the DULCE alignment go, in the same namespace?
roba: submits a proposal ...
<laurent_oz> IM answer to Jano, I'd rather remove the DUL
alignment than having two namespaces
<mlefranc> I have the same assumption than you do Rob and Kerry
<eparsons> This would be the proposal ? Can we vote first to
use one namespace for terms covered in SOSA, adding more axioms
in SSN that are consistent with SOSA text definitions - and
then vote on what to do with new terms
<KJanowic> Keep in mind that sosa does not know about ssn (but
ssn does import sosa)
<laurent_oz> +1 to RobA saying that we need to have a
consistent set of definitions with different ways of consuming
it.
roba: we can always use documentation to flag that more axioms
are available for SOSA terms in the SSN ontology
<laurent_oz> Reminder: Prov-O precedent: has published a Data
Model and an Ontology
<roba> +1
<ahaller2> +1
<KJanowic> +1
<mlefranc> +1
<SimonCox> +1
<MattPerry> +1
<DanhLePhuoc_> +1
<KJanowic> we are voting for " use one namespace for terms
covered in SOSA, adding more axioms in SSN that are consistent
with SOSA text definitions - and then vote on what to do with
new terms"
<Linda> +1
+1
<KJanowic> btw, this is not the case. we are always using the
wrong example :-)
<RaulGarciaCastro> 0
<kerry> +1 to what rob said!
<laurent_oz> +1
roba: so, we're talking about SSN introducing axioms about
terms defined in the SOSA namespace
... and that these axioms must be consistent with the textual
definition in in SOSA
KJanowic: asks whether we changed context halfway through
<KJanowic> yes, in the *next*
<mlefranc> I don't think we changed.
roba: I don't think we changed here [but it's not the full
story]
... we just voted to introduce axioms in SSN to SOSA terms
ahaller2: hmmm, we might not get to the end here.
... perhaps we can provide a clearer set of definition
<KJanowic> jtandy, we did not vote on that. this is my point
ahaller2: I offer to do this if we don't get to the decision
<KJanowic> yes, we have NOT voted on using one namespace
<mlefranc> what about the namespace of the new terms ?
eparsons: I think we're clear on one namespace
<SimonCox> 'kicking the can down the road' ?
ahaller2: roba's vote precedes the decision about one or two
namespaces
<KJanowic> yes, to ahaller2
roba: we need to ask "one namespace for what"
... one namespace for the terms + additional axioms for those
terms
KJanowic: look at the votes, one was yes, the other was no
<mlefranc> agreed KJanowic
roba: tried to break down the problem in discrete chunks
... we might have another namespace for new terms
<KJanowic> roba: yes, absolutely
<mlefranc> or not, would prefer not :-)
eparsons: more than happy to go around this again, still mostly
lost, but desperate to help
<ahaller2> +1 for jtandy!
<KJanowic> roba: I was just explaining that we did not vote on
"just using one namespace" (see above)
<ahaller2> thanks a lot!
<mlefranc> thanks !!
<KJanowic> thanks a lot!
bye!
<roba> thanks guys
<ahaller2> thanks
<RaulGarciaCastro> Bye!
<LarsG> Cheers
<ChrisLittle> Bye and thanks
<eparsons> bye everyone
<kerry> bye!
Summary of Resolutions
1. [17]Approve last week's minutes
[End of minutes]
Received on Friday, 24 February 2017 09:54:32 UTC