W3C home > Mailing lists > Public > public-ssn-cg@w3.org > July 2012

Re: [ExternalEmail] Proposal for a new organisation of the SSN Ontology

From: Michael Compton <Michael.Compton@csiro.au>
Date: Mon, 9 Jul 2012 12:10:54 +1000
Message-ID: <14B51322-F526-4473-9152-7781C330D96D@csiro.au>
To: <public-ssn-cg@w3.org>
Dear all,

The outcome of recent discussion seemed to be that we should start  
collecting uses of the SSN ontology and listing and analysing  
ontologies with which it is used.  I've started a page on the wiki


for this purpose, based on the SSN-XG one (at http://www.w3.org/2005/Incubator/ssn/wiki/Review_of_Sensor_and_Observations_Ontologies)

I was thinking that here we could start to list ontologies that people  
think might be useful to the community (ontologies that people have  
either used with the SSN ontology or developed for use with the SSN  

Once we have started to develop a list, there are probably better ways  
to maintain the libraries or profiles as discussed earlier, but this  
should give us a start.

Please add.


On 14/06/2012, at 23:25 , Oscar Corcho wrote:

> I fully agree with Manfred proposal.
> I see also that Raúl has already commented the need of presenting
> extensions that are normally appearing when we are trying to reuse  
> the SSN
> ontology.
> Maybe a good idea would be to identify all those areas and start a  
> similar
> process of listing those ontologies that have been described in those
> areas, analysing them, and proposing a few that could be useful and  
> well
> aligned with SSN, to increment uptake.
> Oscar
> -- 
> Oscar Corcho
> Ontology Engineering Group (OEG)
> Departamento de Inteligencia Artificial
> Facultad de Informática
> Campus de Montegancedo s/n
> Boadilla del Monte-28660 Madrid, España
> Tel. (+34) 91 336 66 05
> Fax  (+34) 91 352 48 19
> El 13/06/12 11:40, "Manfred Hauswirth" <manfred.hauswirth@deri.org>
> escribió:
>> Dear all,
>> Kerry.Taylor@csiro.au wrote:
>>> Michael and all,
>>> I strongly support this redesign, at least in principle (as Michael
>>> knows!).  I haven't had a chance to look at the detail, yet, I am  
>>> afraid.
>> +1
>>> A point of minor disagreement, though. I think your message implies
>>> that (roughly) the SSN is "complete" and
>>> everything else is covered by "stubs" and "examples".
>>> I think there is real extension work to be done (appropriately
>>> modularised), perhaps around "activation",
>>> "humans as sensors" and possibly systems, platforms and deployment  
>>> too.
>> +1
>> Plus we need extension for energy and network structure. This is
>> something you come across when working on practical cases immediately
>> and it is fairly straight-forward but necessary. We extended SSN in
>> SPITFIRE (www.spitfire-project.eu) in these respects and can provide
>> this as a starting point for discussions.
>> SPITFIRE in my opinion is particularly interesting (shameless
>> self-promotion) for providing input to SSN as we combine RDF,  
>> ontologies
>> and REST (6LowPAN and CoAP - currently being standardized by IETF) in
>> this project to make sensor networks look like normal Web resources,
>> i.e., development should boil down to the same abstractions like  
>> normal
>> Web development - but there is a lot of work you need to do under the
>> hood to support this in a nice way.
>> CoAP will be the standard. The IoT people are going for REST.  
>> Ontologies
>> in IoT are all over the place. We need to support this from SSN's  
>> side
>> and get the necessary uptake outside the core Web community.
>> Best,
>> Manfred
>>> Kerry
>>>> -----Original Message-----
>>>> From: Michael Compton [mailto:Michael.Compton@csiro.au]
>>>> Sent: Friday, 8 June 2012 5:07 PM
>>>> To: public-ssn-cg@w3.org
>>>> Subject: [ExternalEmail] Proposal for a new organisation of the SSN
>>>> Ontology
>>>> Hi,
>>>> It's pretty quiet on this list so far, so here is a try at  
>>>> generating
>>>> some discussion.
>>>> I've been thinking about the SSN Ontology and wondering if it  
>>>> wouldn't
>>>> be better organised into a set of ontologies, rather than just  
>>>> one.  A
>>>> couple of reasons:
>>>> - the SSO (stimulus sensor observation) pattern isn't usable on  
>>>> its own
>>>> - the SSN ontology introduces things like deployments, which aren't
>>>> sensor only, and
>>>> - I keep getting asked about the dolce alignment and how it's all  
>>>> very
>>>> nice and all, but it seems like lots of users would rather maybe  
>>>> know
>>>> it's there, but not have to use it
>>>> So attached I have a first cut at doing this.
>>>> - It starts with the SSO as an independent ontology.
>>>> - Then importing this is the SSNO, which should amount to all the
>>>> 'sensor only' concepts.
>>>> - From there is SSNO plus the alignment as a separate branch and
>>>> another branch which adds Systems and Devices and then Platforms  
>>>> and
>>>> Deployments.
>>>> - Finally, is the whole thing aligned to DUL.  This should be  
>>>> pretty
>>>> much equivalent to the original ontology.
>>>> I hope that's able to be navigated with the attached files.   My
>>>> expectation is that the sensor ontology could be just the first two
>>>> (SSO & SSNO) and then from there as a community we could define a
>>>> number of useful stubs and examples - so take the systems and
>>>> deployments branch as a stub of how to incorporate systems, devices
>>>> and deployments.  For example, units, time, location, etc might  
>>>> also
>>>> be useful stubs.  These together with a set of examples and  
>>>> libraries
>>>> (say of definitions of real devices and domains) could really  
>>>> help to
>>>> get people started with the ontology and help us share common
>>>> fragments.
>>>> All this should give us a somewhat more minimal ontology and a  
>>>> better
>>>> organisation of extensions etc.
>>>> Thoughts, ideas, comments, disagreements, etc..?
>>>> Michael
>> -- 
>> Prof. Manfred Hauswirth
>> Digital Enterprise Research Institute (DERI)
>> National University of Ireland, Galway (NUIG)
>> http://www.manfredhauswirth.org/
Received on Monday, 9 July 2012 02:11:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:38:17 UTC