Re: ssn requirements usecase, and what this means for "principles"

I agree on having "extensibility" and "data validation" included as
non-functional requirements (or Principles).

As Simon pointed out, the "profiling" requirement may arise as a need for
using a reduced/customized version of the general model, e.g. a lite
version of the SSN ontology. Indeed, in the Marine observations - eMII
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MarineObservationsEMII>
use case, Simon describes the need for validating whether profiles for
observation data models validate against the standard. Looking at the rest
of use cases related to the "profiling" requirement (only one, Satellite
data processing
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SatelliteDataProcessing>),
it seems to me that the interest is more on data validation than on
creating profiles from the standard (something that we cannot control
anyway). So I would remove the word "profiling" from the requirement, label
it as a non-functional requirement, and re-define it as something similar
to "Data validation: It should be possible to check data compliance to the
standard model". Then, we can discuss if this is something we want to
propose as Best Practice for the standards released by the group.

Any thoughts?

Alejandro

On 5 May 2015 at 05:45, <Simon.Cox@csiro.au> wrote:

>  ‘profile’ is sometimes used in the sense of ‘constrained subset of a
> more general model’ – often by fixing cardinalities (within the ranges
> permitted), or specifying the range-set for a property or attribute. You
> then look at testing compliance to the ‘profile’. That could lead to the
> apparent conflation.
>
>
>
> *From:* Kerry.Taylor@csiro.au [mailto:Kerry.Taylor@csiro.au]
> *Sent:* Tuesday, 28 April 2015 11:22 PM
> *To:* public-sdw-wg@w3.org
> *Subject:* [ExternalEmail] ssn requirements usecase, and what this means
> for "principles"
>
>
>
> Column AB for ssn on the UCR spreadsheet is  labelled “ Profiling, e.g.
> for checking compliance to standard model”.
>
>
>
> While trying to clarify this it occurs to me that this wraps 2
> requirements into 1, that I think should be separate (inheriting this
> combination from the OGC “profile” notion, I think).
>
>
>
> I would propose replacing it by both
>
>
>
> 1.       Extensibility – it should be possible to extend the recommended
> structure to support domain-specific  models; and
>
> 2.       It should be possible to express and validate compliance to
> models
>
>
>
> Next, I would like to raise these to the level of applying (or not) to all
> our deliverables as they are not SSN-specific.
>
> Are these “vision”-ish enough to be thought of as “principles” in the
> current discussion? Or at least as over-arching non-functional requirements?
>
>
>
> Finally, I would like to propose that while (1) should be addressed by the
> group, (2) looks out of scope to me. Furthermore, technology for (2) such
> as RDF data shapes is still too immature for our purposes.
>
>
>
> What do you think?
>
> Kerry
>
>
>
>
>
>
>



-- 
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