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

And that means that we need to define what a “profile“ means to us. Since there seems to be an OGC definition of “profile”, I suggest that someone who knows what that is (I don’t) adds that term to the glossary [1] (if that is the definition we want to use…).



From: []
Sent: Tuesday, May 05, 2015 5:46 AM
Subject: RE: ssn requirements usecase, and what this means for "principles"

‘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:<> []
Sent: Tuesday, 28 April 2015 11:22 PM
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?

Received on Wednesday, 6 May 2015 08:36:23 UTC