Re: [ExternalEmail] New SSN version

I'd be interested to hear what others have to say about such a  
property.  I would think it's too OGC specific to include in the  
ontology itself; however, it sounds like what you are working with is  
exactly the kind of example that shows how the ontology could be used  
with OGC services, so it's very much the sort of thing that should be  
included in the ontology report and the kind of example we want to  
show off.

Michael





On 18/08/2010, at 9:12 , P.Barnaghi@surrey.ac.uk wrote:

> thanks. "hasLocation" property from DOLCE perfectly fits with our  
> example.
>
> Another probably missing property in the ontology is a link to  
> Sensor Observation Service. The ontology includes properties to  
> define process, inputs and outputs; but I couldn't find any property  
> to link a sensor description to its Observation Service; something  
> like "hasSensorObservationService".
>
> Regards,
> Payam
>
> ________________________________________
> From: Michael Compton [Michael.Compton@csiro.au]
> Sent: 17 August 2010 01:30
> To: Barnaghi P Dr (Electronic Eng)
> Cc: public-xg-ssn@w3.org
> Subject: Re: [ExternalEmail] New SSN version
>
> Yes there has been discussion on this point.  While we aren't going to
> define any sort of location ontology, we need hooks for locations to
> live.  So there could/should be a relation like hasLocation that links
> anything to its location.  DOLCE covers all these sorts of things
> nicely, so the intention over the last little bit has been to use the
> DOLCE alignment to get this and other things.  So for now why not just
> add hasLocation, and that should fit nicely with the DOLCE version.
>
> Michael
>
>
>
>
>
> On 16/08/2010, at 21:52 , p.barnaghi@surrey.ac.uk wrote:
>
>> Hi Michael, Laurent,
>>
>> I am trying to create an example using the ontology. I can't find
>> the attribute to define location of a sensor deployment.  I have
>> forgotten discussions about this. Is there any attribute to define
>> location for sensors?
>>
>> Thanks,
>> Payam
>>
>>
>> -----Original Message-----
>> From: public-xg-ssn-request@w3.org [mailto:public-xg-ssn-request@w3.org
>> ] On Behalf Of Michael Compton
>> Sent: 16 August 2010 03:02
>> To: public-xg-ssn@w3.org WG
>> Subject: Re: [ExternalEmail] New SSN version
>>
>> Thanks Laurent, my full list of changes is at the end of this email.
>>
>> I realised that the reason that I didn't have the property chains for
>> observes (/measures) is that I couldn't work out how to do it (and
>> still can't) in TopBraid free edition.  Unless someone can sort this
>> out, I think it might be worth shifting to to Protege - though the  
>> use
>> of top braid was due to an earlier group discussion, so there might  
>> be
>> some good reason that I have forgotten about.
>>
>> One issue to note :
>>
>> At the July 29 meeting we discussed adding a link (here called
>> deployedOnPlatform) from Deployment to Platform (there is already one
>> from System to Platform).  We discussed using a role composition to
>> link the related properties here.  I had a hard time deciding between
>>
>> deployedSystem o onPlatform --> deployedOnPlatform
>>
>> and
>>
>> hasDeployment o deployedOnPlatform --> onPlatform
>>
>> Basically the discussed idea was that both systems and deployments
>> should have a relationship with the platform: i.e. deployment is  
>> often
>> attaching a sensor to a platform, so one could think of it as "I
>> attached this sensor to this platform", or "I deployed this system,  
>> oh
>> and the system is attached to that platform.
>>
>> The two role compositions achieve essentially the same thing - the
>> difference is in what you can derive.  With the first option, if  
>> there
>> are some onPlatform relations asserted, then the deployedOnPlatforms
>> can be derived, but if deployedOnPlatform relations are asserted,
>> nothing about onPlatform can be derived.  The opposite is the case  
>> for
>> the other option.
>>
>> The problem is that in asserting one we assert a point of view on the
>> ontology, about which of these relations is primary, that makes the
>> other point of view inconvenient and essentially means that the other
>> sort of reasoning can't be done.
>>
>> Currently I asserted nothing.  I'm not sure if anyone case a
>> particular opinion of preference, just thought I would raise it and
>> see.
>>
>> Thanks
>> Michael
>>
>>
>>
>> Changes
>> =========
>>
>> - fixed procedure (its domain and range, and updated Observation)
>>
>> - added madeObservation (inverse of procedure)
>>
>> - added observes : links a sensor to the qualities/properties that it
>> observes and is defined using a (actually 2) role composition.
>>
>> - add forProperty : links a measurement capability to the property
>> that it relates to (e.g. if a sensor can sense multiple properties,
>> this can relate the capabilities to the properties)
>>
>> - Added from Payam's operating and survival model :
>> OperatingRange
>> OperatingProperty
>> EnvironmentalOperatingProperty
>> MaintenanceSchedule
>>
>> hasOperatingCondition
>> hasOperatingRange
>>
>> SurvivalRange
>> BatteryLifetime
>> SystemLifetime
>> EnvironmentalSurvivalRange
>>
>> hasSurvivalCondition
>> hasSurvivalRange
>>
>>
>> - Added from deployment model :
>> DeplymentRelatedProcess
>> Deployment
>> (Installation/commissioning and removal/decommissioning would live
>> under DeploymentRelatedProcess too)
>>
>> Platform
>>
>> attachedSystem
>> deployedOnPlatform
>> deployedSystem
>> deploymentProcessPart
>> hasDeployment
>> onPlatform
>>
>> startTime (for deployment)
>> endTime
>>
>>
>>
>>
>>
>> On 14/08/2010, at 0:36 , Laurent.Lefort@csiro.au wrote:
>>
>>> Hi,
>>>
>>> The new version of the SSN XG ontology with the changes resulting
>>> from yesterday's teleconference and with the extra annotations added
>>> by my script is now available at
>>> http://www.w3.org/2005/Incubator/ssn/wiki/images/3/36/Ssn.xml
>>>
>>> Your feedback is welcome on these additions via the mailing list and
>>> we'll have a discussion to hopefully wrap this up (the new classes
>>> and properties, the PURL namespace, and the changes in the
>>> documentation script) at the next teleconf.
>>>
>>> Next week, I also want to discuss our need for better graphics. Can
>>> I ask for volunteers to prepare some figures for the main classes of
>>> the ontology and also for the deployment and platform classes? I
>>> think it should be possible to feed COE with the right subset of the
>>> ontology thanks to my effort to re-order it by "section" (see my
>>> ideas below).
>>>
>>> NEW CLASSES AND PROPERTIES
>>>
>>> There are some changes which needs to be documented between the
>>> ontologies released this week and the previous version
>>> (SensorBasis.owl with the old namespace) published last month).
>>>
>>> I have added the following classes as extra Measurement  
>>> capabilities:
>>> Precision, ResponseTime, Sensitivity, Selectivity, DetectionLimit
>>> and Drift This addition was announced in this email:
>>> http://lists.w3.org/Archives/Public/public-xg-ssn/2010Jul/0009.html
>>>
>>> Michael has also added a few classes (see list below). Most of them
>>> were already added in the version I released last week.
>>>
>>> Michael has added a few property chain axioms in relation to our
>>> discussion at the last teleconf:
>>>
>>> - observes (= measures) http://www.w3.org/2005/Incubator/ssn/wiki/SSN#observes
>>>
>>> madeObservation o observedProperty <= observes
>>>
>>> (madeObservation is inverse of procedure-1)
>>>
>>> hasMeasurementCapability o forProperty <= observes
>>>
>>> - deployed on platform
>>> http://www.w3.org/2005/Incubator/ssn/wiki/SSN#deployedOnPlatform
>>>
>>> deployedSystem o onPlatform <= deployedOnPlatform
>>>
>>> CHANGE OF PURL NAMESPACE
>>>
>>> The new version uses a namespace base "http://purl.oclc.org/NET/ssnx/ssn
>>> " which is declared on purl.org (I could not get /NET/ssn/...).
>>> I've opted for a 303 permanent url (the type which corresponds to
>>> Semantic Web resources). It is set up to redirect the users to the
>>> wiki page with the documentation http://www.w3.org/2005/Incubator/ssn/wiki/SSN
>>> (I've use a configuration which is the same as what was done for
>>> the MUO ontology).
>>>
>>> Examples:
>>> - http://purl.org/NET/ssnx/ssn#Sensor will get you to http://www.w3.org/2005/Incubator/ssn/wiki/SSN#Sensor
>>>
>>> Please test if the configuration works for your environment.
>>>
>>> NEW DOCO
>>>
>>> I have re-worked the documentation generation tool and find a more
>>> direct way to transform the output to the wiki (cleanup with Amaya
>>> first and then copy via Firefox to Open Office and then export as
>>> MediaWiki and finally fix the local links. I'm quite happy with the
>>> result. I hope you'll like it too.
>>>
>>> I have also done some experiments to create HTML-formatted content
>>> out of the wiki content. I'll report on my findings next week.
>>>
>>> NEED FOR BETTER GRAPHICS (separate wiki page and XG report)
>>>
>>> For the Ontology report, we need better graphics to each sections of
>>> the ontology (the "sections" are derived from the rdfs:seeAlso
>>> annotations defined for the generation of the documentation http://www.w3.org/2005/Incubator/ssn/wiki/SSN
>>> )
>>>
>>> The "see also" annotations are designed to correspond to the yet to
>>> be added "manually written" documentation pages for the ontology (=
>>> the figures plus the text which will also be included in the
>>> ontology deliverable)
>>>
>>> The intent is that one wiki page will be created for each URL used
>>> for the see also annotations.
>>> Note: for the http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Base we
>>> need to create a [[SSN Base]] wiki page.
>>>
>>> There are many wiki pages yet to be created to support this scheme.
>>> We need to be sure if we have the right sections first. Having the
>>> graphics would help.
>>>
>>> Now that the classes in the OWL file are also ordered by section, it
>>> should be easier to use a tool like the CMAP Ontology Editor (http://www.ihmc.us/groups/coe/
>>> ) to create the figures.
>>>
>>> Cheers
>>> Laurent
>>>
>>> -----Original Message-----
>>> From: Compton, Michael (ICT Centre, Acton)
>>> Sent: Friday, 13 August 2010 4:09 PM
>>> To: Lefort, Laurent (ICT Centre, Acton)
>>> Subject: changes
>>>
>>> Changes
>>> =========
>>>
>>> Added from Payam's model:
>>>
>>> OperatingRange
>>> OperatingProperty
>>> EnvironmentalOperatingProperty
>>> MaintenanceSchedule
>>>
>>> hasOperatingCondition
>>> hasOperatingRange
>>>
>>> SurvivalRange
>>> SurvivalProperty
>>> BatteryLifetime
>>> DeviceLifetime (has replaced SystemLifetime)
>>> EnvironmentalSurvivalRange
>>>
>>> hasSurvivalCondition
>>> hasSurvivalRange
>>>
>>> ---------------
>>>
>>> Added from deployment model:
>>>
>>> DeplymentRelatedProcess
>>> Deployment
>>> (Installation/commissioning and removal/decommissioning would live
>>> under DeploymentRelatedProcess too)
>>>
>>> Platform
>>>
>>> attachedSystem
>>> deployedOnPlatform
>>> deployedPlatform
>>> deployedSystem
>>> deploymentProcessPart
>>> hasDeployment
>>> onPlatform
>>>
>>> startTime
>>> endTime
>>>
>>> -------------------
>>>
>>> General
>>>
>>> observes
>>> madeObservation
>>> forProperty
>>>
>>>
>>
>>

Received on Friday, 20 August 2010 00:22:14 UTC