- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Thu, 14 Jul 2016 10:01:17 -0700
- To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Simon.Cox@csiro.au
- Cc: rob@metalinkage.com.au, danh.lephuoc@tu-berlin.de, armin.haller@anu.edu.au, public-sdw-wg@w3.org, kerry.taylor@anu.edu.au
- Message-ID: <5787C55D.2080700@ucsb.edu>
Hi, This is actually fine and there will be no problem with doing this (also) on the SOSA-Core classes as long as we use subclassing as alignments and hence do not try to change the semantics of core classes after the fact. Vertical modules introduce new/finer distinctions to the same domain of interpretation, horizontal modules broaden the domain of interpretation. Jano On 07/14/2016 09:43 AM, Joshua Lieberman wrote: > I agree with subclasses as “higher” modules of the core. > Specialization is probably the clearest form of vertical addition to > the ontology. Less clear are additional classes that may have the > effect of more specificity but structurally extend the ontology. I’m > wondering specifically about the case of simply adding constraint > clauses on to the core classes and their properties in higher modules. > Beyond the issue of how to identify the presence or absence of such > clauses, it seems like a good idea to encourage by way of > description the same usage of the core classes that is enforced > “higher up” by constraints. The goal would be to minimize > inconsistencies between use of the core vocabulary and use of the same > entities with added constraints. > > Maybe this means that we should stick with applying the more > expressive constraints to subclasses only, not the core vocabulary. > > —Josh > > >> On Jul 14, 2016, at 1:42 AM, Simon.Cox@csiro.au >> <mailto:Simon.Cox@csiro.au> wrote: >> >> Both subclasses (i.e. refinements – e.g. the sub-classes of >> sensing-devices that you mentioned earlier) and classes for auxiliary >> concepts that are not subclasses of the core might be added in >> vertical models (e.g. add ‘site-visit’, ‘study-location’ to the >> sampling module, or ‘laboratory’ to the observation module). The >> latter don’t extend the scope of the application, though I guess >> strictly they extend the scope of the ontology. >> Subclasses cannot imply a horizontal extension – that’s inconsistent >> with the set-theoretic definition of subclass. >> The core is as generalized as possible for the classes that are >> named. Minimum semantics but maximum scope. >> Simon >> *From:*Rob Atkinson [mailto:rob@metalinkage.com.au] >> *Sent:*Thursday, 14 July 2016 2:29 PM >> *To:*Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au >> <mailto:Simon.Cox@csiro.au>>; janowicz@ucsb.edu >> <mailto:janowicz@ucsb.edu>; jlieberman@tumblingwalls.com >> <mailto:jlieberman@tumblingwalls.com>; rob@metalinkage.com.au >> <mailto:rob@metalinkage.com.au> >> *Cc:*danh.lephuoc@tu-berlin.de <mailto:danh.lephuoc@tu-berlin.de>; >> armin.haller@anu.edu.au <mailto:armin.haller@anu.edu.au>; >> public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>; >> kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au> >> *Subject:*Re: SOSA core - procedures vs devices >> Can you give an example of a "vertical" adding classes - as opposed >> to a "horizontal". I guess it applies to blank nodes for >> owl:restrictions which are technically owl:Classes (?) >> If its adding sub-classes - wouldnt these be further horizontal (but >> outside the core) domain extensions? >> Rob >> On Thu, 14 Jul 2016 at 12:11 <Simon.Cox@csiro.au >> <mailto:Simon.Cox@csiro.au>> wrote: >> >> In order to accomplish this, the core would be essentially just a >> short list of classes, and a short list of the basic properties >> that might link them plus other key properties (e.g. “result”). >> Some subclassing, but no domains/ranges or owl:Restrictions. >> Think of them as stub classes or abstract classes covering the >> core application, primarily to get everyone onto the same page >> when talking about sensing, observing, actuating and sampling. >> Lightweight applications might go no further. >> Vertical modules would add constraints (global and/or local), >> further sub-classes, and additional classes and properties. >> Simon >> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu >> <mailto:janowicz@ucsb.edu>] >> *Sent:*Thursday, 14 July 2016 10:48 AM >> *To:*Joshua Lieberman <jlieberman@tumblingwalls.com >> <mailto:jlieberman@tumblingwalls.com>>; Rob Atkinson >> <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>> >> *Cc:*Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au >> <mailto:Simon.Cox@csiro.au>>;danh.lephuoc@tu-berlin.de >> <mailto:danh.lephuoc@tu-berlin.de>;armin.haller@anu.edu.au >> <mailto:armin.haller@anu.edu.au>;public-sdw-wg@w3.org >> <mailto:public-sdw-wg@w3.org>;kerry.taylor@anu.edu.au >> <mailto:kerry.taylor@anu.edu.au> >> >> *Subject:*Re: SOSA core - procedures vs devices >> >> but I am presuming that the core vocabulary "carries" similar >> semantics to the intensive (vertical) additions >> >> >> IMHO, vertical modules are further restricting the interpretation >> of SOSA-core terms while horizontal modules further broaden the >> domain of discourse. >> >> Best, >> Krzysztof. >> >> On 07/13/2016 04:44 PM, Joshua Lieberman wrote: >> >> All of the possible extensive modules may be hard to predict >> and plan, but I am presuming that the core vocabulary >> "carries" similar semantics to the intensive (vertical) >> additions, just as description instead of prescription. >> >> --Josh >> Joshua Lieberman, Ph.D. >> Principal, Tumbling Walls Consultancy >> Tel/Direct: +1 617-431-6431 >> jlieberman@tumblingwalls.com >> <mailto:jlieberman@tumblingwalls.com> >> >> >> On Jul 13, 2016, at 18:33, Rob Atkinson >> <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>> wrote: >> >> As long as the core is designed and explained in the >> context of the set of modules necessary. normally not >> working out these scopes in advance tends to lead to an >> ugly kitchen sink model, but we are fortunate to have >> enough experience available to keep the core skinny :-) >> >> On Thu, 14 Jul 2016 7:09 am Krzysztof Janowicz >> <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>> wrote: >> >> Ø we need something separate to handle the fact >> that different types have very different >> deployment description requirements, and this may >> require subclassing to handle in-situ sensors, vs >> location being part of the observation, and maybe >> vs sensors whose location can be calculated (e.g. >> satellite in orbit)? >> Of course. But this won’t be in the core. >> >> Agreed. >> >> >> >> >> On 07/13/2016 01:43 PM,Simon.Cox@csiro.au >> <mailto:Simon.Cox@csiro.au>wrote: >> >> Øwe need something separate to handle the fact >> that different types have very different >> deployment description requirements, and this may >> require subclassing to handle in-situ sensors, vs >> location being part of the observation, and maybe >> vs sensors whose location can be calculated (e.g. >> satellite in orbit)? >> >> Of course. But this won’t be in the core. >> *From:*Rob Atkinson [mailto:rob@metalinkage.com.au] >> *Sent:*Wednesday, 13 July 2016 4:26 PM >> *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>;armin.haller@anu.edu.au >> <mailto:armin.haller@anu.edu.au>;public-sdw-wg@w3.org >> <mailto:public-sdw-wg@w3.org>;kerry.taylor@anu.edu.au >> <mailto:kerry.taylor@anu.edu.au> >> *Subject:*Re: SOSA core - procedures vs devices >> That all makes sense to me, but still missing >> something I thin: a deployed device has its own >> spatio-temporal context related, but not the same >> as the feature of interest, and a simulation or >> model will generate observations. So i am happy >> with sensor as a general term but we need >> something separate to handle the fact that >> different types have very different deployment >> description requirements, and this may require >> subclassing to handle in-situ sensors, vs >> location being part of the observation, and maybe >> vs sensors whose location can be calculated (e.g. >> satellite in orbit)? >> On Wed, 13 Jul 2016 at 15:25 Krzysztof Janowicz >> <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>> wrote: >> >> Hi, >> >> I would propose the following: >> >> 1. A Procedure describes the *workflow* used >> to perform (carry out) the act of >> observing/sensing. The simplified example I >> used today was temperature. One procedure >> will require to mount a thermometer 2m above >> ground in an area that is neither directly >> exposed to sun or wind. Another procedure >> will use the very same sensor type >> (thermometer) but explain how to place it >> within a certain layer of soil. In the first >> case, the observed property is air >> temperature; in the second case, it is soil >> temperature. Procedures are key to >> interoperability and the *reproducibility* of >> results. This notion of a procedure aligns >> well with Gil's work on workflows as well as >> provenance work more broadly. In the SSN-SSO >> pattern we stated that an Observation >> /satisfies/ a (observation) Procedure and >> that a Sensor /implements/ such Procedure. >> There are several types (subclasses) of >> Procedure. I can think of at least two: >> SamplingProcedure and >> ObservationProcedure.While this may sound >> trivial, please note that a single procedure >> is used to carry out *millions* of >> observations in the same way as one uses the >> same recipe over and over again to bake a >> chocolate cake. >> >> 2. The act of using a Sensor to arrive at a >> Result for an ObservedProperty of a >> FeatureOfInterest by receiving some Stimulus >> is what I would call Sensing/Observing (see >> alsohttps://www.w3.org/2005/Incubator/ssn/ssnx/ssn#Sensing). >> IMHO, we do not need that level of detail in >> SOSA-core but certainly in other (vertical & >> horizontal) modules. The *most* important >> aspect here is that every single use of a >> sensor creates a new (and unique) Sensing. >> This is why Procedure and Sensing are very >> different. There are thousands of (popular) >> procedures but billions of sensing acts. Why >> would one care about the act of sensing? One >> example would be to use it to capture >> contextual information, e.g., about the >> weather and its potential impact on a certain >> observation, other observations required to >> interpret the results, and so on. If I am not >> mistaken, this particular context is also >> known as ObservationContext. >> >> 3. So what Thing is carrying out this Sensing >> by following a certain Procedure? I believe >> that we should call this the *Sensor* and >> very explicitly state that humans can be >> sensors, devices can be sensors, simulations >> can be sensors, and so forth. This leads to >> the interesting question of whether we should >> subclass sensor and I would propose not to do >> so in SOSA-core. Given that we merely have >> the expressivity of RDF at our disposal, we >> do not want to end up with statements such as >> Human subClassOf Sensor. Even more >> importantly, I would not try to find a better >> name than Sensor. Terms such as Device will >> exclude humans and simulations and thus are >> too specific. Terms such as System are too >> broad. Sensors are things that perform >> sensing and humans clearly do so, e.g., with >> their eyes. >> >> 4. Try to avoid terms such as process and >> event whenever possible. >> >> What do you think? Does this make sense? >> >> Best, >> Krzysztof >> >> >> >> On 07/12/2016 04:50 PM,Simon.Cox@csiro.au >> <mailto:Simon.Cox@csiro.au>wrote: >> >> Yes, but I think we were thinking more >> that a procedure uses a device, during an >> activity. >> When describing the agents of >> observation, it depends how close you >> want to look. There are multiple layers >> of encapsulation. That was probably the >> motivation for bundling them together in >> SensorML and O&M, but SSN chose to be >> more careful about distinguishing >> physical devices from workflows – which I >> certainly understand as well. >> The word ‘process’ is overloaded, and in >> particular is used in contradictory ways >> in BFO and O&M, and SensorML uses it in >> both ways. So now I prefer to avoid it >> altogether. >> *From:*Joshua Lieberman >> [mailto:jlieberman@tumblingwalls.com] >> *Sent:*Wednesday, 13 July 2016 9:10 AM >> *To:*Cox, Simon (L&W, >> Clayton)<Simon.Cox@csiro.au> >> <mailto:Simon.Cox@csiro.au> >> *Cc:*danh.lephuoc@tu-berlin.de >> <mailto:danh.lephuoc@tu-berlin.de>;janowicz@ucsb.edu >> <mailto:janowicz@ucsb.edu>;armin.haller@anu.edu.au >> <mailto:armin.haller@anu.edu.au>;public-sdw-wg@w3.org >> <mailto:public-sdw-wg@w3.org>;kerry.taylor@anu.edu.au >> <mailto:kerry.taylor@anu.edu.au> >> *Subject:*Re: SOSA core - procedures vs >> devices >> Sorry I missed the call today. So a >> device “runs” (l:n) a procedure in / >> during (1:n) a process? >> —Josh >> >> On Jul 12, 2016, at 6:39 >> PM,simon.cox@csiro.au >> <mailto:simon.cox@csiro.au>wrote: >> >> I’ve put some notes and a diagram >> explaining my understanding of the >> consensus from today’s call here >> https://www.w3.org/2015/spatial/wiki/SOSA_Ontology#Procedures_vs_Devices >> >> >> Note >> >> 1.I have adjusted the names of the >> classes to avoid ambiguity between >> the re-usable things and the events >> when they are used >> >> 2.I have not yet implemented this in >> SOSA-Core – its just a proposal for now. >> >> 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 >> <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 <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 >> <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 <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 >> <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, 14 July 2016 17:01:53 UTC