Re: ISSUE-3 (Modules for sensor, data and process): Ontology modules aligned with use cases [sensor ontology - - 09.12.15 ]

A couple of points about this one

- I think showing how the ontology relates to the use cases is an  
important idea.  Doing so would certainly portray both the ontology  
and the use cases in a way that would make them both accessible and  
understandable relative to each other.

- Actually structuring the ontology around these use cases does seem  
unusual.  A modular structure is good idea, but it should more  
represent the natural boundaries and groupings of the ideas.

- A view or representation of the ontology, while conforming to it's  
logical meaning, doesn't have to represent it's modular structure or  
all it's parts.  For example if the ontology is split into modules A,  
B and C, but a particular use case required B, parts of A and only a  
little of C, then it would seem natural to me to highlight those  
aspects in the presentation of the ontology for that use case, perhaps  
presenting the concepts in a way suitably showing those parts together  
and not highlighting the 'real' modularisation of the ontology.  So  
why not produce such views (i.e. just as diagrams) suitable for  
explaining particular points and use cases, and if it's natural and  
correct why not think about it in terms of that representation when  
think about the use case?

- I think I think this because I always see an ontology and its  
representation as distinct things - though many seem to disagree, so  
here's my explanation.  Like any data structure or model an ontology  
does not have to be exposed in it's entirity, or at all, to 'users'.   
Just as in programming where we build data structures internally, to  
say objects, and then expose interfaces to them, here we can build the  
ontology as a model, but expose or represent it in any way that  
respects its meaning but is more appropriate to the task at hand.  For  
example we have already discovered in the group that there is a  
division between caring mostly about data (observations) and mostly  
about sensors.  These groups have different requirements of and  
different focusses on the ontology.  So it would seem natural then to  
present to say an observation focused user a view of the ontology that  
highlights and looks like their view of the world, rather than  
presenting the ontology in its whole, which may not at all look like  
or feel like their view of the world.  Here I mean present in either  
an interface for using the ontology, or document explaining it etc.

So I think that we should structure the ontology in the most natural  
way, but, in the sense in those last two points, I think Laurent's  
suggestion has some merit in both explaining and potentially  
validating the ontology for the particular uses that we have identified.


On 17/12/2009, at 18:57 , Simon Cox wrote:

> +1
> -----Original Message-----
> From: [ 
> ] On
> Behalf Of John Graybeal
> Sent: 17 December 2009 07:33
> To: Semantic Sensor Network Incubator Group WG
> Subject: Re: ISSUE-3 (Modules for sensor, data and process): Ontology
> modules aligned with use cases [sensor ontology -
> wl - 09.12.15 ]
> The Issue database didn't seem to have a way to add comments, so I'll
> just make a brief note via the mail.  I don't know that this follows.
> I think device discovery, data discovery, and provenance can easily
> cut across any and all aspects of a sensor, and therefore can easily
> exercise all aspects of the ontology. _Structuring_ the ontology to
> match the use case seems an unusual step from that standpoint.  It
> should be able to validate the use case, but that doesn't require a
> mirrored structure, does it?
> John
> On Dec 16, 2009, at 12:43, Semantic Sensor Network Incubator Group
> Issue Tracker wrote:
>> ISSUE-3 (Modules for sensor, data and process): Ontology modules
>> aligned with use cases [sensor ontology -
>> # -  
>> 09.12.15 ]
>> Raised by: Laurent Lefort
>> On product: sensor ontology -
> wl
>> - 09.12.15
>> The Use cases reviewed in
>> are organised into sub-categories:
>> - Device discovery	
>> - Data discovery
>> - Process/provenance
>> The ontology structure should mirror three sub-categories so that we
>> can identify and discuss "simple" uses cases where only one sub-
>> module is needed and complex use cases where all the modules are
>> needed.

Received on Friday, 18 December 2009 01:09:27 UTC