- From: Simon Cox <simon.cox@jrc.ec.europa.eu>
- Date: Mon, 10 Aug 2009 13:54:07 +0200
- To: <Laurent.Lefort@csiro.au>, <public-xg-ssn@w3.org>
> Most of the attempts to capture O&M into an ontology have gone to the
non-normative UML version of O&M (what you call the HollowWorld model) which
is what is used in practice used to derive (generate) useful XML schemas
compliant (inspired by?) the O&M specs.
This is still wrong/misleading.
The HollowWorld distribution includes the normative O&M model, alongside the
ISO Harmonized Model, and some other stuff.
There is little that is 'non-normative' in HollowWorld.
In fact (as of last week) the HollowWorld 'trunk' version contains both O&M
v1.0 (as published by OGC) and the O&M model as found in the 'Committee
Draft' of ISO 19156 (i.e. O&M v2.0 as scheduled for publication as an ISO
standard in a year or so).
O&M has dependencies on many other parts of the ISO Harmonized model, but
the interface classes are clear.
If what you are saying is that people don't want to generate an ontology for
the whole of HollowWorld, then I agree that would be largely beside the
point.
What I find curious about this discussion, in the context of the 'semantic
web', is that O&M and HollowWorld are quite honest about the dependencies on
external resources.
Inevitably, this can lead to a rather large graph, if you chase them all
down.
But the point of the 'web' is deferred resolution of references, so you only
need look at a sub-graph at any one time, with interface classes/resources
represented as URIs.
OTOH many of the ontologies I see coming out of the semantic web community
have 'self-contained' as part of their design criteria.
This seems to miss out on the 'web' part of 'semantic web'.
Simon Cox
European Commission, Joint Research Centre,
Institute for Environment and Sustainability,
Spatial Data Infrastructures Unit, TP 262
Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
Tel: +39 0332 78 3652
Fax: +39 0332 78 6325
mailto:simon.cox@jrc.ec.europa.eu
http://ies.jrc.ec.europa.eu/simon-cox
SDI Unit: http://sdi.jrc.ec.europa.eu/
IES Institute: http://ies.jrc.ec.europa.eu/
JRC: http://www.jrc.ec.europa.eu/
-----Original Message-----
From: public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org] On
Behalf Of Laurent.Lefort@csiro.au
Sent: Monday, 10 August 2009 12:31
To: public-xg-ssn@w3.org
Cc: simon.cox@jrc.ec.europa.eu
Subject: RE: purpose/goals for observations ontologies
Hi Simon,
The UML classes definitions including in your presentation
(http://www.w3.org/2005/Incubator/ssn/wiki/images/4/46/O%26M_Property_Dictio
nary.pdf) corresponds to what I would call the O&M abstract model.
Most of the attempts to capture O&M into an ontology have gone to the
non-normative UML version of O&M (what you call the HollowWorld model) which
is what is used in practice used to derive (generate) useful XML schemas
compliant (inspired by?) the O&M specs. That's where the "rest of O&M"
arrives with all these dependencies to other stuff which are partially
implicit in the specification.
I think Holger's intent was to find an approach where we can stick at a
level which is somewhere in-between the minimal one (your definition of O&M)
and the one where the ontology fully mirrors the corresponding bits of the
HollowWorld UML model because this 2nd approach leads to a result which is
judged by the group to be too big (too verbose?).
Eventually, we want to have an ontology (or a set of ontology modules) which
can be used on its own and which would also be useful when it is used to
annotate web services developed out of OGC specs. We have recognised that we
need to design is structure so that it can hold both the sensor and the
observation perspectives. What we are trying to do know is trying to define
how these two perspectives can cohabit together. This *basic* design of the
ontology structure Holger is talking about is at that level (to get a
"basic O&M structure" that enables the alignment/inclusion of an O&M
ontology *with a sensor ontology*).
On O&M, I agree that more analysis work is required to understand the
nuances between the different approaches. Some of the geoscience use cases
you have worked on fits naturally well in the O&M abstract model. We are
interested in your views on the ontologies developed with different use
cases in mind, especially OBOE (and maybe SERONTO
http://www.w3.org/2005/Incubator/ssn/wiki/SERONTO_Review ), and also other
application domain like climate sciences and aero-meteorology where more
tweaking of the abstract model may be required. We are also interested in
your views on what's the basic structure should contain.
I hope this helps.
Laurent
PS: I also think that it is very hard to discuss (understand) an ontology
just on the basis of a "simple" UML model especially when this model is
designed so that it can be exploited with a Model Driven approach like ISO
19136/FullMoon
http://www.eresearch.edu.au/fullmoon-a-framework-for-processing-uml-models.
My personal experience is that the weakest link of any UML model I've seen
in terms of Semantics are the properties definitions, especially when (and
this is often the case in OGC world) they have loose semantics to enable the
creation of different "profiles". And when these properties point to
external vocabularies or definitions brought from other specs, it is very
hard to know what they really mean or to find where to stop the inclusion of
other bits sourced elsewhere.
-----Original Message-----
From: public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org] On
Behalf Of Simon Cox
Sent: Monday, 10 August 2009 4:41 PM
To: Neuhaus, Holger (ICT Centre, Hobart); public-xg-ssn@w3.org
Subject: RE: purpose/goals for observations ontologies
Hold on a moment - what do you think "all of O&M" is?
The OGC spec(*) (Part 1 - Observation Schema) includes a mere 5 classes in
the normative part, 3 of which are included from other ontologies like
SensorML! How much more basic can you get?
Part 2 (Sampling Features) has 13 classes, but the ontology is simple.
I'm afraid that some of last weeks telecon, and emails like this, suggest
that the analysis of 'O&M' by this group has in some cases not involved
reading the original sources.
As a consequence some significant misunderstandings are being propagated.
(*) Unless I'm mistaken, and O&M refers to something different?
Simon Cox
European Commission, Joint Research Centre, Institute for Environment and
Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi,
2749, I-21027 Ispra (VA), Italy
Tel: +39 0332 78 3652
Fax: +39 0332 78 6325
mailto:simon.cox@jrc.ec.europa.eu
http://ies.jrc.ec.europa.eu/simon-cox
SDI Unit: http://sdi.jrc.ec.europa.eu/
IES Institute: http://ies.jrc.ec.europa.eu/
JRC: http://www.jrc.ec.europa.eu/
-----Original Message-----
From: public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org] On
Behalf Of Holger.Neuhaus@csiro.au
Sent: Monday, 10 August 2009 03:34
To: public-xg-ssn@w3.org
Subject: RE: purpose/goals for observations ontologies
Hi all,
I pretty much agree with what's being said here. So, we shouldn't cover all
of O&M in the SSN Ontology, and it's also out of scope to develop an
ontology for O&M. But - we need to have some kind of "basic O&M structure"
that enables the alignment/inclusion of an O&M ontology. We should have a
discussion about that at the next telecon. We also need to discuss which bit
to amend/extend/add to the ontology.
In addition, I agree with John that the 'use cases will have to be refined
and prioritized (and a fair number excluded [...]) if they are to be the
basis of our determination of what to include or not include in the model.'
And yes, that is "real work", so that we'd have to discuss that part at the
next telecon as well.
Comments are welcome.
Cheers,
Holger
Dr. Holger Neuhaus
Post-Doctoral Research Fellow
Tasmanian ICT Centre
CSIRO
Phone: +61 3 6232 5547 | Fax: +61 3 6232 5000 holger.neuhaus@csiro.au |
www.csiro.au | www.csiro.au/science/TasICTCentre.html
Address: GPO Box 1538, Hobart TAS 7001, Australia
The Tasmanian ICT Centre is jointly funded by the Australian Government
through the Intelligent Island Program and CSIRO. The Intelligent Island
Program is administered by the Tasmanian Department of Economic Development,
Tourism and the Arts.
PLEASE NOTE
The information contained in this email may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
email in error, please delete it immediately and notify the sender by return
email. Thank you. To the extent permitted by law, CSIRO does not represent,
warrant and/or guarantee that the integrity of this communication has been
maintained or that the communication is free of errors, virus, interception
or interference.
Please consider the environment before printing this email.
-----Original Message-----
From: public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org] On
Behalf Of Kevin R. Page
Sent: Wednesday, 5 August 2009 7:54 AM
To: public-xg-ssn@w3.org
Subject: Re: purpose/goals for observations ontologies
Hello John, comments inline,
On Tue, 2009-08-04 at 13:52 -0600, John Graybeal wrote:
> On Aug 4, 2009, at 10:20 AM, Kevin R. Page wrote:
>
> > We should recognise that both user-oriented (data) and process-
> > oriented
> > (sensor) use cases exist (as reflected in current OGC standards).
>
> I am having trouble with this framing; maybe just an ambiguity, or
> maybe more.
So I know there are those on this list who are more familiar, and can no
doubt elaborate more eloquently, on the distinctions made in current OGC
standards - please do (and correct me :) )
I guess my bracketed 'data' and 'sensor' above show where I see the
differences (and I don't want to overdo them as differences).
I'll start with an (over-simplistic) description of where I'm coming
from:
1) sometimes, we might start with a sensor network, with it's elements
described according to the device ontology. We might use the ontology to
manage the sensor network. We might use the descriptions of sensor
properties and data capabilities to pick out particular sensors, and from
there get to the data that sensor has produced. Absolutely, this is the
device ontology.
2) at other times we might start with a large amount of data produced by a
sensor network, and from that we want to create useful information.
It's more than just data; we care about concepts like observations,
measurements, context, so that we can process the data effectively.
Descriptions about the actual sensors is metadata to this data; that's not
so say it isn't important, it very much is (e.g. as provenance, or to infer
the classification of the data from the sensor capabilities), but we're
starting from the data.
I don't think there's any horrific difference or schism here. There's
obviously overlap - it's the same data. Sometimes you come at different
parts of it from different directions.
And it's much easier to bring these two viewpoints together in the RDF world
than the XML Schema world.
So a device ontology might have some O&M concepts included; an O&M ontology
might have some device concepts included; it might be one big ontology
(don't have to use all of it, after all).
As long as whatever ontology (or ontologies) we end up with enables us to
just have devices, or just have observations, and get from one to the other
as and when we can (or want to) link that data.
>From another perspective: semantic web technologies can be applied to
improve sensor networks; but I think it's equally, if not more, important
that sensor networks and the data they output become part of the semantic
web of data. These aren't orthogonal tasks.
> I agree that use cases about the (actual output) data *produced by*
> sensors exist.
and it matters that this data was produced by sensors; these use cases need
to capture and encode this.
> Use cases about the data *describing* actual sensors (name, size,
> color, and all that) also exist. The latter is what I thought a device
> ontology should encompass.
Yes. And perhaps 'device ontology' is a clearer description of that ontology
if it doesn't include O&M concepts.
> So, which of these did you mean by 'user-oriented (data)'? (I suggest
> that 'user-oriented' is entirely a function of the user, and some
> users care only about the devices, not their data; so maybe this isn't
> an optimal term.)
Indeed, I am not fond of the term.
So I think 'user-oriented (data)' as originally cited is the former - but
the data describing sensors is still there as (vital) metadata.
(Illustrative use of the term 'metadata' - I'm not sure I believe in
metadata enough to classify what is and isn't data ;) )
> Will the introduction of the 'process oriented' way of looking at the
> device -- the framing introduced by SensorML, which I have heard
> summarized as "the sensor is a process", right? -- tell me more, less,
> or the same information as a 'simple descriptive model'?
About the device? The same. I think the 'process' concept encapsulates the
manner by which the observation was gathered. When this is a sensor, the
information about the 'process' instance is (or could be) the simple
descriptive model / the device ontology.
> Put another way, is there necessarily any difference between the two?
I'd rather there not be. I think we can do both.
As Krzysztof's recently arrived email says, a good starting place is
probably to extend the observation concept in the sensor ontology.
> To tie this back to the larger question I started with, It just seems
> to me that where some element comes from a process, the ontology will
> naturally describe that ("sensor producesDataRecord recordType1").
And when I come across an instance of 'recordType1' I want to know that it
was produced by an instance of 'sensor'.
Regards,
Kevin
--
Kevin R. Page
krp@ecs.soton.ac.uk http://www.ecs.soton.ac.uk/info/people/krp
Intelligence, Agents, Multimedia University of Southampton, UK
Received on Monday, 10 August 2009 11:54:52 UTC