Re: Proposal for a new organisation of the SSN Ontology

Yes, this was very much the idea I was going for.  Sorry, I didn't  
really mean that there is nothing more to add to the whole thing, but  
more that we should abstract and modularise first, and very much have  
a set of modules that can be selected for a particular purpose -  
libraries as I wrote, or profiles as Raúl wrote.

The idea of stubs as starting points was that a common stub helps to  
share and interoperate between different extensions.  For example, if  
there were the SPITFIRE networking extension, and a couple of other  
networking ontologies that we probably have between us, I think we are  
better to provide a very small extension/stub that contains the common  
terms and definitions, showing how they relate to the SSNO, and then  
provide the various networking ontologies as extensions that share  
then this common stub.  Users could then select between the extensions  
when creating the profiles that Raúl talked about.  I think organising  
things that way (rather than just having all the extensions directly  
from the SSNO) should allow for better modularity and alignment  
between different users of the ontology.

If we decide to have just one networking extension and dictate that's  
the one to use, then it's no issue, but then that's more limiting and  
prescriptive and doesn't really help people use the ontology who come  
with their own bits already or help anyone in the community share data  
and extensions.

That's my reasoning about how we should organise the extensions.    
Definitely as a community we should be contributing the bits that we  
have found necessary in our own work - networking, actuators,  
observation collections/timeseries, etc.

I'm glad it's got us talking.

Michael








On 13/06/2012, at 19:57 , Raúl García Castro wrote:

> Dear all,
>
> I haven't taken a look in detail to the ontology files but I also  
> think
> that it is a good idea.
>
> For example, in the SemsorGrid4Env project we had to extend the SSN
> ontology to cover further requirements that we had (e.g., representing
> observation collections such as those in the O&M specification).
>
> So, it would be nice to have, instead of a big ontology, a set of
> ontology modules that allow covering different requirements. This can
> lead to have different "profiles" or combinations of modules to be  
> used
> in different scenarios.
>
> Kind regards,
>
> El 08/06/12 09:07, Michael Compton escribió:
>> 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
>>
>>
>
>
> -- 
>
> Dr. Raúl García Castro
> http://delicias.dia.fi.upm.es/~rgarcia/
>
> Ontology Engineering Group
> Departamento de Inteligencia Artificial
> Universidad Politécnica de Madrid
> Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
> Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Thursday, 14 June 2012 00:53:09 UTC