Approve last week's minutes

<eparsons> 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> 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: https://www.w3.org/2015/spatial/wiki/NamespaceIssue

<ahaller2> 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> 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> http://www.w3.org/ns/ssn/ for SSN and http://www.w3.org/ns/sosa/ for 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> 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!