See also: IRC log
<ahaller2> scribe: ClausStadler
<ahaller2> Approving last meeting's minutes https://www.w3.org/2016/11/22-sdwssn-minutes
<kerry> +1
+1
<RaulGarciaCastro> +1
<ahaller2> +1
<ahaller2> Patent Call
RESOLUTION: Approving last meeting's minutes https://www.w3.org/2016/11/22-sdwssn-minutes
Updates to SSN ontology, especially actuation, modularization (several currently written things have been superseeded by discussions now), sosa-core naming,
spec generation has been looked into; couple of issues that can be solved, either manually or hacking into the python code
kerry: not sure if all issues with specgen can be fixed, such as cardinality restrictions / multiple restrictions with the same property
classes and properties not linked in the output, difficulties with hash / slash uris
KJanowic: manual changes will be lost after regeneration; bad idea
ahaller2: will try to fix issues in the code
<KJanowic> IMHO, this has great potential for going terribly wrong.
<KJanowic> ahaller2: changing in the code would probably the better way to go
<KJanowic> I can update the intro section (which I also originally drafted)
<KJanowic> I can do the sosa parts
volunteers needed to go throught the text: such as introduction, goals
<Zakim> kerry, you wanted to suggest to armin we meet in person to go through this
KJanowic: volunteers for introduction (and possibly other parts)
<KJanowic> I volunteer to do all the SOSA related parts
ahaller: happy to rewrite modularization part, update the graph, there are no longer imports, no longer call it 'core' because it isn't
kerry: work on the dulce alignment, equivalence class axioms - need to be norminative
ahaller: will alot of the equivalent axioms point to the dulce part?
kerry: refer to the SSN classes in the old namespace; decision was made on the observation part, others need to be worked on
ahaller: if label gets changed, its no longer the same thing
ahaller2: danh and raul to work on the table (https://www.w3.org/2015/spatial/wiki/Mapping_Table)
<RaulGarciaCastro> It seems you cannot hear me
<RaulGarciaCastro> Yes
<kerry> claus! not that table!
my bad - which table were you referring to?
<RaulGarciaCastro> I’ve been taking a look to the usage of the SSN ontology: haven’t found many datasets using it. I have also searched for ontologies reusing SSN
<RaulGarciaCastro> I collect the analysis I’ve made and will share with the group
<RaulGarciaCastro> I’m working in the analysis of the usage of SSN (right now not on the implementation report)
<KJanowic> Claus: by the table we mean the implementation report overview table
kerry: implementation report is not in the deliverable, its a separate document
Thanks for clarification
<RaulGarciaCastro> I don’t know :)
ahaller2: Its not decided yet, others put the implementation report into the deliverable, it could be an annex
<RaulGarciaCastro> I’m working on it; right now the problem is the lack of datasets (i.e., the coverage is low)
<kerry> issue-85 ?
<trackbot> issue-85 -- remove someValues from restriction on hassubsystem -- raised
<trackbot> http://www.w3.org/2015/spatial/track/issues/85
<KJanowic> https://www.w3.org/2015/spatial/track/actions/226
<KJanowic> Long version short, our current axiom is fine and in line with Mereology and its axiomatizations and also what DUL meant by hasPart. that said, I do not see any harm by removing the existential quantification
kerry: If the presence of the existencal restriction improves reasoning, it would be a strong reason to keep it.
<RaulGarciaCastro> +1 to removing the restriction, I don’t like forcing systems to include hasPart with themselves just to be consistent
<KJanowic> You do not enforce this
<KJanowic> for two reasons, first because of our haspart definition and second because the OWA
<RaulGarciaCastro> OK
ahaller2: Can the restrictions be moved into the DUL aligment?
<KJanowic> My point is that the forall quantification alone will not do anything. it only states that if there would be something it would be inferred to be a (sub)system. It does *not* restrict the predicate
ahaller2: Advantage would be that it makes the new SSN more lightweight
<kerry> agreed! that is the point!
KJanowic: The forall restriction does: If there would be a usage of the hasSubSystem relation to something, such as chewinggum then the chewing gum would be a system. It does not restrict the usage of hasSubSystem.
<KJanowic> Claus: the forall restriction, not the existential restriction
<KJanowic> sorry kerry for not being clear, I meant how we used the local closure in other parts of the system definition: https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#System
<kerry> dont park it!
<kerry> -1
<ahaller2> Vote between removing the existential restrictions on hasSubSystem or keeping the existential or removing universal and existential
<KJanowic> Too many or clauses :-)
<kerry> removing someValues from restriction on hasSubSystem ISSUE 85
<KJanowic> It is also really low priority (this may all change depending on the other changes we do)
<kerry> removing someValues from restriction on hasSubSystem ISSUE 85
<KJanowic> If kerry believes that this is a big step in usability of ssn, I am fine to go with kerry's suggestion
<ahaller2> kerry to decide on issue 85 as editor of the new SSN
<KJanowic> +1
<RaulGarciaCastro> +1
<ahaller2> +1
+1
<KJanowic> Okay, I will look into this
ahaller2: There were no recent updates or comments on the annotation table. Decision in one of the last meetings to introduce our own rdfs:comments and annotations. Anyone who has objections to these annotations should raise an issue in the table.
<Zakim> kerry, you wanted to say I did edit it a bit --- marked as "(kerry)" and to say I did edit it a bit --- marked as "(kerry)" in table and to suggest that won't make the WD
<kerry> issue-86
<trackbot> issue-86 -- Annotation for a feature of interest --- and why do we need it at all? -- raised
<trackbot> http://www.w3.org/2015/spatial/track/issues/86
<KJanowic> I would strongly be against removing the FOI class
<kerry> moved to issue-94
<kerry> issue-94?
<trackbot> issue-94 -- Why do we need the sosa-core Feature of interest class at all? -- raised
<trackbot> http://www.w3.org/2015/spatial/track/issues/94
KJanowic: FeatureOfInterest class has use cases, such as for filtering by that class in a faceted browser. Also, features that have no yet observed data could already be declared as instances of that class in advance.
<KJanowic> Many reasons not to do that: APIs, faceted browsing, FOI that have not yet been sensed, creating subclasses,...
<RaulGarciaCastro> +1 to leave it
<ahaller2> +1 to KJanowic
+1 to leave it
<KJanowic> I would vote -1 on removing , i.e., +1 on leaving it in there
<ahaller2> + leaving
<ahaller2> +1 leaving
<KJanowic> +1 on leaving
<kerry> close issue-94
<trackbot> Closed issue-94.
<KJanowic> also keep observableproperty
<KJanowic> we also closed 85, right?
<ahaller2> close issue-85
<trackbot> Closed issue-85.
<KJanowic> thanks for the productive meeting, bye bye
<RaulGarciaCastro> Bye!
<ahaller2> bye, thanks
<kerry> bye!
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/several has been/several currently written things have been/ Succeeded: s/equivalenc/equivalence/ Succeeded: s/dolce/dulce/ Succeeded: s/chewin /chewing/ Succeeded: s/KJanowic: The exsistential restriction does/KJanowic: The forall restriction does/ Found Scribe: ClausStadler Inferring ScribeNick: ClausStadler Present: kerry ahaller2 RaulGarciaCastro kjanowic Regrets: scott simon Found Date: 29 Nov 2016 Guessing minutes URL: http://www.w3.org/2016/11/29-sdwssn-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]