- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Wed, 27 Jul 2016 20:12:35 -0700
- To: Simon.Cox@csiro.au, rob@metalinkage.com.au, armin.haller@anu.edu.au, kerry.taylor@anu.edu.au
- Cc: public-sdw-wg@w3.org
- Message-ID: <7fae925a-bdcc-36dc-c1ab-c97ea028d428@ucsb.edu>
So far we even have a little bit of OWL in there. The point is not whether this is RDF, RDFS, or OWL but that core is as lightweight as possible and targets the broader Web audience in a similar way as schema.org does. Core should have a reduced axiomatization, i.e., minimize ontological commitments. On 07/27/2016 07:40 PM, Simon.Cox@csiro.au wrote: > > Øthe core has RDFS > > Probably not. The only bit of RDFS we are even _/considering/_ using > is subClassOf, and Jano is making a strong case against even that. > > *From:*Rob Atkinson [mailto:rob@metalinkage.com.au] > *Sent:* Thursday, 28 July 2016 11:32 AM > *To:* Armin Haller <armin.haller@anu.edu.au>; Rob Atkinson > <rob@metalinkage.com.au>; Kerry Taylor <kerry.taylor@anu.edu.au> > *Cc:* public-sdw-wg@w3.org > *Subject:* Re: Updated SOSA core RE: SOSA core - procedures vs devices > > Vertical is easy - i understand that - the core has RDFS - then we > need OWL-DL axioms in a vertical module - and i guess alignments to > other ontolofies are a vertical module. > > its the horizontal partioning that interests me - presumably there > will be a module for sensing, one for describing devices etc. The > core will presumably be common so that the relationships between > things at this detail level dont need to import all the complex and > potentially un-defined detail - i.e. we dont want to repeat O&M having > to define an GF_AnyFeature class because there was no core set of > concepts for it to use :-) > > On Thu, 28 Jul 2016 at 09:28 Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>> wrote: > > Hi Rob, > > The core was always proposed to be only one lightweight ontology. > The other vertical modules build upon this core to define more > axiomatically the relations between the classes in the core and > also introduce new classes/relationships that are specific to the > extension. The core itself is envisioned to be very lightweight so > that it can be used in a similar way than schema.org > <http://schema.org> is used these days on many webpages. > > Cheers, > Armin > > *From: *Rob Atkinson <rob@metalinkage.com.au > <mailto:rob@metalinkage.com.au>> > *Date: *Wednesday, 27 July 2016 3:03 pm > *To: *Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>>, Rob Atkinson > <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>> > *Cc: *"public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>" > <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>> > > > *Subject: *Re: Updated SOSA core RE: SOSA core - procedures vs devices > > *Resent-From: *<public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>> > *Resent-Date: *Wednesday, 27 July 2016 3:03 pm > > I know this is all a bit fraught because of multiple different > communities of practice having their own preferences, but I'd like > to make a few suggestions that may help... > > The beauty of using RDF as the platform is that we have existing > vocabularies that allows us to declare equivalence of terms in > use, and we can make just the statements that we find necessary, > without stopping others combining these easily with other statements. > > That said, I dont necessarily believe that RDF based tooling is a > given here - I would envisage much of the potential usage to be > based on JSON-LD with clients picking out just the metadata they > need. Hence I dont see why one file is a necessary constraint. > Most IoT uses will simply be to define the semantics of terms in a > payload, and clients will not actually dereference and worry about > the internal structure of the definition space. > > One of Armin's earlier proposals about modules had about 5 modules > in the "core" - i.e. a finer grained horizontal partitioning. I > would have thought someone describing a device would appreciate > having a device description module, without having to assess how > much of the module is relevant - and someone deploying it another > module that imports it etc. i was expecting something like a > sosa-om to introduce the observation-centric concepts - but be > part of the "core" set of modules One role for a sosa-core would > be simply to lay out the separation of concerns of the process > (the five base classes, and any subclasses necessary for > decoupling of other modules (i.e. the sosa-om does not need to > import a sosa-procedure module which provides a model of how a > sensor relates to a procedure - it just uses the base class from > sosa-core) > > There is probably an interesting measure for what % of a module a > Use Case requires - and how many use cases each element in a > module supports > > rob > > On Wed, 27 Jul 2016 at 12:11 Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> wrote: > > So I understood the “core” was to be comprised of essential > Iot-driven terms and was also semantically-simple ie RDF-alone > or RDFS but always ensuring compatibility with OWL-DL. I’d be > happy to have no subclass axioms, too. And in only one file. > I am not sure whether we agreed , or whether I just assumed > the one-file part.. > > For the non-core modules I was expecting “horizontal” –style > expressivity – ie OWL DL is fine as appropriate. Furthermore, > the non-core modules (or module?) would aim to separate > concerns insofar as this increases usability. > > Ø- or another supporting diagram that has the same underlying > module structure, but shows the extensions (OWL axioms) etc > attached to each concept-defining module in the main hierarchy. > > I agree this is essential, when the terms are new and > independent of the old ssn, (which they appear to be to me in > the sosa proposal). If they *are *ssn terms, on the other > hand, I don’t need such a diagram as the horizontal/non-core > ssn modules will do that alignment properly anyway, and will > also provide the documentation you ask for. I think such a > diagram aimed at users of the core alone might be useful for > users at publication time, then, but is not essential for the > team’s internal use where we are now. Not that it would hurt. > > Kerry > > *From:*Rob Atkinson [mailto:rob@metalinkage.com.au > <mailto:rob@metalinkage.com.au>] > *Sent:* Wednesday, 27 July 2016 11:50 AM > *To:* Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>>; Rob Atkinson > <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>> > *Cc:* public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> > > > *Subject:* Re: Updated SOSA core RE: SOSA core - procedures vs > devices > > Personally i do find it approaching K's proposal - but the > roles of modules a little blurred. The implication is even > more modules at this level of granularity - or another > supporting diagram that has the same underlying module > structure, but shows the extensions (OWL axioms) etc attached > to each concept-defining module in the main hierarchy. > > On Wed, 27 Jul 2016 at 10:18 Kerry Taylor > <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>> wrote: > > Agreed! This looks to me very little like K’s proposal as > I understood it. Am in the middle of composing a longer > version of something like this. > > >“But if we really have a tabula rasa,” > > We do not – refer to the charter please. > > *From:*Rob Atkinson [mailto:rob@metalinkage.com.au > <mailto:rob@metalinkage.com.au>] > *Sent:* Wednesday, 27 July 2016 10:08 AM > *To:* Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>; > Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>; janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>; jlieberman@tumblingwalls.com > <mailto:jlieberman@tumblingwalls.com> > > > *Cc:* danh.lephuoc@tu-berlin.de > <mailto:danh.lephuoc@tu-berlin.de>; public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>; Kerry Taylor > <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>> > *Subject:* Re: Updated SOSA core RE: SOSA core - > procedures vs devices > > Hi - whilst I'm not as familiar with the details the > amount of modules and the logical structure fit my > expectation. I think however that the explanations of > these will need some work to make them accessible. In > particular sosa-om and sosa-sam explanations only help if > you are intimately familiar with these. It would help even > at this early stage to perhaps describe what these > contain, and why they are not part of the core. If what > they are is an extension of sosa-core that does not define > new entities, but uses additional expressivity available > in a language then perhaps we can come up with a naming > convention that reflects the role of each module? eg > sosa-ssn-align ? > > If modules are doing multiple things - like extending > scope, adding axioms and performing alignments (declaring > equivalent classes) then this is a departure from > Krzysztof's proposal - which may not be a bad thing but > means that the modularisation strategy needs to be > re-articulated and taken into account. > > Rob > > On Wed, 27 Jul 2016 at 08:28 <Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>> wrote: > > Currently Sensing is a subclass of Observing (or > Observation), which is a subclass of Activity. That > was my proposed ordering – seeing ‘sensing’ as a > subset of ‘observing’ to be consistent with OGC usage, > where ‘Observation’ covers not only sensing but also > forecasting, simulation, human-observing (which is a > combination of sensing and application of knowledge). > > But if we really have a tabula rasa, then we should > consider the best terminology and correct hierarchy – > maybe ‘estimating’ is a more general term. > > But definitely the order in that hierarchy should be > resolved. > > Simon > > *From:*Armin Haller [mailto:armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>] > *Sent:* Wednesday, 27 July 2016 7:58 AM > *To:* janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; > Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>>; > jlieberman@tumblingwalls.com > <mailto:jlieberman@tumblingwalls.com> > *Cc:* danh.lephuoc@tu-berlin.de > <mailto:danh.lephuoc@tu-berlin.de>; > public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>; > Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> > > > *Subject:* Re: Updated SOSA core RE: SOSA core - > procedures vs devices > > The proposal we arrived to now looks good to me. > > The only change, where I second Simon is, that we > should rename Actuation to Actuating. That is then > aligned to Sensing and also implies an Activity. The > same applies to Observation which I would rename > Observing. Although, I am not sure if we need the > Observing class in the core if we have Sensing anyway. > > *From: *Krzysztof Janowicz <janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>> > *Reply-To: *"janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>" <janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>> > *Date: *Wednesday, 27 July 2016 6:34 am > *To: *"Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>" > <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>, > Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>, > "jlieberman@tumblingwalls.com > <mailto:jlieberman@tumblingwalls.com>" > <jlieberman@tumblingwalls.com > <mailto:jlieberman@tumblingwalls.com>> > *Cc: *"danh.lephuoc@tu-berlin.de > <mailto:danh.lephuoc@tu-berlin.de>" > <danh.lephuoc@tu-berlin.de > <mailto:danh.lephuoc@tu-berlin.de>>, > "public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>" > <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>>, > Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> > *Subject: *Re: Updated SOSA core RE: SOSA core - > procedures vs devices > > I made some cosmetic changes and pushed them to > github. I am going to make another series of changes > that are a bit bigger and thus will leave them in > https://github.com/w3c/sdw/blob/kjanowicz-ssn/ssn/rdf/sosa.ttl > for now until we agree on them. Most of this is from > our last discussion about procedures and platforms. > > Jano > > On 07/18/2016 10:01 PM, Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au> wrote: > > I’ve just pushed an update to the SOSA Core ontology > > https://github.com/w3c/sdw/tree/simon-ssn/ssn/rdf > > in particular > https://github.com/w3c/sdw/blob/simon-ssn/ssn/rdf/sosa.ttl > > > This includes the hierarchy shown on the wiki page > https://www.w3.org/2015/spatial/wiki/SOSA_Ontology > > I’ve cleaned up the class names a bit, and added > documentation on all elements. > > Simon > > -- > > Krzysztof Janowicz > > Geography Department, University of California, Santa > Barbara > > 4830 Ellison Hall, Santa Barbara, CA 93106-4060 > > Email: jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu> > > Webpage: http://geog.ucsb.edu/~jano/ > <http://geog.ucsb.edu/%7Ejano/> > > Semantic Web Journal: http://www.semantic-web-journal.net > -- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: jano@geog.ucsb.edu Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Thursday, 28 July 2016 03:13:09 UTC