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

Hello Kerry,

It may be woth noting that your number two - validation of compliance - is
also captured in one of the BP requirements in the spreadsheet: It should
be possible to validate data (column N).

When looking critically at the two requirements (extensibility and
possibilities for validation) I think that yes, they are both out of scope,
because there are no uniquely spatial aspects to them. But they both would
do well as non-functional requirements (or Principles) and I think this
adds to the desirability of having a list of  non-functional requirements
somewhere.

About the argument that technology is stilll too immature: I think we
should try to separate requirements and possible solutions to requirements.
Perhaps we can foresee that a certain requirement will be hard to meet,
given the current state of affairs. Still I think it is worthwhile to
record such a requirement. For one thing, it could be an extra motivation
for working on progress that would make it possible to meet the requirement
some time in the future.

Regards,
Frans






2015-04-28 15:21 GMT+02:00 <Kerry.Taylor@csiro.au>:

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



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