Re: SSN requirements

Yes, this is a good idea. Yet, I would prioritize to have the complete and
refined list of SSN (plus the other deliverables' reqs.) by next telecon,
vote for the FPWD, and then start thinking about the relations between SSN
reqs. and Best Practice deliverable. Does this make sense?

Regards,
Alejandro

On 28 May 2015 at 18:34, Frans Knibbe <frans.knibbe@geodan.nl> wrote:

> Hello Alejandro, Kerry,
>
> (Please excuse me for responding to a not so recent thread)
>
> There are several requirements for the SSN deliverable. There seems to be
> agreement that we won't go into the specifics of whether the current SSN
> vocabulary adequately addresses those requirements. But wouldn't it be a
> good idea to relate these requirements to the Best Practices deliverable
> too? In theory, the SSN developers could decide not to support a
> requirement in SSN because it would be out of scope for SSN - a clash
> with the noble design principles of modularity and separation of concerns.
> In that case we would have a requirement that can not be met. If such a
> requirement would be in the sights of the BP deliverable, then the BP
> deliverable could still recommend a way of meeting the requirement -
> perhaps using SSN plus some other things.
>
> Greetings,
> Frans
>
> 2015-04-29 14:24 GMT+02:00 <Kerry.Taylor@csiro.au>:
>
>>  Agreed. Those things are not explicitly addressed by ssn. Either SSN
>> should be extended a little bit to do it, or alternatively we could simply
>> recommend a way of doing it with ssn and give an example. I think the
>> former is almost certainly better, at least where the necessary extension
>> is small and the use case is in demand. We should consider ontology
>> modularity here – separate a group of such concepts into a separate owl
>> file to make it easier to ignore ( a little known revision of ssn has done
>> this breaking up  for what is there already).
>>
>>
>>
>> Kerry
>>
>>
>>
>>
>>
>> *From:* Alejandro Llaves [mailto:allaves@fi.upm.es]
>> *Sent:* Wednesday, 29 April 2015 8:30 PM
>> *To:* Frans Knibbe
>> *Cc:* SDW WG Public List
>> *Subject:* Re: SSN requirements
>>
>>
>>
>> Hi Frans,
>>
>>
>>
>> wrt 5.3 Georeferenced sensor data
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#GeoreferencedSensorData>,
>> SSN does not specify which vocabulary to use, but it is possible to
>> georeference sensor data and there are many examples out there, e.g. using
>> GeoSPARQL.
>>
>>
>>
>> Regarding the other requirements, 5.5 Mobile sensors
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MobileSensors>,
>> 5.7 Moving features
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MovingFeatures>,
>> and 5.8 Observation aggregations
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#ObservationAggregations>,
>> SSN does not meet them (AFAIK). However, the final SSN report
>> <http://www.w3.org/2005/Incubator/ssn/XGR-ssn/> does not either
>> explicitly say that sensors and features (FOIs) have to be static, nor that
>> observations cannot be aggregated.
>>
>>
>>
>> I would leave the analysis of which requirements are met by existing
>> standards/recommendations (and which of them are not) for the corresponding
>> SSN, Coverage, and Time deliverables. Let's see what the rest think...
>>
>>
>>
>> Best regards,
>>
>> Alejandro
>>
>>
>>
>> On 28 April 2015 at 14:09, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>>
>> Hello Alejandro,
>>
>>
>>
>> About requirements 5.3
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#GeoreferencedSensorData>,
>> 5.5
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MobileSensors>,
>> 5.7
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MovingFeatures>
>> and 5.8
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#ObservationAggregations>
>> : Is it correct to assume that the current SSN vocabulary does not meet
>> these requirements? Would it make sense to be explicit about that?
>>
>>
>>
>> Greetings,
>>
>> Frans
>>
>>
>>
>>
>> --
>>
>> Frans Knibbe
>>
>> Geodan
>>
>> President Kennedylaan 1
>>
>> 1079 MB Amsterdam (NL)
>>
>>
>>
>> T +31 (0)20 - 5711 347
>>
>> E frans.knibbe@geodan.nl
>>
>> www.geodan.nl
>>
>> disclaimer <http://www.geodan.nl/disclaimer>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Alejandro Llaves
>>
>> Ontology Engineering Group (OEG)
>>
>> Artificial Intelligence Department
>>
>> Universidad Politécnica de Madrid
>>
>> Avda. Montepríncipe s/n
>>
>> Boadilla del Monte, 28660 Madrid, Spain
>>
>>
>>
>> http://www.oeg-upm.net/index.php/phd/325-allaves
>>
>>
>>
>> allaves@fi.upm.es
>>
>
>
>
> --
> Frans Knibbe
> Geodan
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
>
> T +31 (0)20 - 5711 347
> E frans.knibbe@geodan.nl
> www.geodan.nl
> disclaimer <http://www.geodan.nl/disclaimer>
>
>


-- 
Alejandro Llaves

Ontology Engineering Group (OEG)

Artificial Intelligence Department

Universidad Politécnica de Madrid

Avda. Montepríncipe s/n

Boadilla del Monte, 28660 Madrid, Spain


http://www.oeg-upm.net/index.php/phd/325-allaves


allaves@fi.upm.es

Received on Friday, 29 May 2015 10:16:27 UTC