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

I don't think there is particular confusion about the term, just people who use it loosely. Geographic information profiles are specified in ISO 19106, and this is the practice that OGC generally follows. The critical ingredient is that a profile is consistent with the original standard, so that an instance conforming to the profile also conforms to the original. A type 2 extension that adds additional elements does not have this characteristic.

Josh

> On May 6, 2015, at 08:08, <Kerry.Taylor@csiro.au> <Kerry.Taylor@csiro.au> wrote:
> 
> Thanks Peter
> – you did better than I (although I thought I found “profiles” that were not “application profiles”...)
>  
> This confusion about the term makes me even happier with my original suggestion (at the bottom of this trail )
>  
> 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
>  
> Kerry
>  
> From: Peter Baumann [mailto:p.baumann@jacobs-university.de] 
> Sent: Wednesday, 6 May 2015 10:02 PM
> To: Little, Chris; Svensson, Lars; Cox, Simon (L&W, Highett); Taylor, Kerry (Digital, Acton); public-sdw-wg@w3.org
> Subject: Re: ssn requirements usecase, and what this means for "principles"
>  
> here it is, pretty fresh (2015-03-13):
>     http://docs.opengeospatial.org/pol/05-020r20/05-020r20.html
> 
> it states:
> AP (Application Profile) -Set of one or more base standards and - where applicable - the identification of chosen clauses, classes, subsets, options and parameters of those base standards that are necessary for accomplishing a particular function [ISO 19101, ISO 19106]
> 
> not very enlightening? well, in practice this means:
> - a profile refers to some standard (which it refines in some way)
>    ex: WCS Application Profile - Earth Observation (EO-WCS) tailors the generic WCS to deal with satellite imagery
> - as such, a profile is a subset of the concepts of said standard (this is what the above definition mainly addresses)
>     ex: EO-WCS only talks about 2D imagery
> - but a profile may also extend, ie: add application specific concepts
>     ex: EO-WCS adds remote sensing metadata (as per EO-Metadata standard), a dedicated search in space/time, etc
> 
> HTH,
> Peter
> 
> 
> On 05/06/15 13:46, Little, Chris wrote:
> Dear SDWWG colleagues,
>  
> I had a quick look on the OGC portal and could not find a definition.
>  
> The Wikipedia definition, “a subset internal to a specification” is at http://en.wikipedia.org/wiki/Profile_%28engineering%29 but does not cite any references or sources.
>  
> The UK government definition is the slightly broader “subsets or combinations of standards” at https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles#glossary
>  
> I am not sure whether or where is the best place to put this on the SDWWG wiki or which definition we prefer.
>  
> Chris
>  
> From: Svensson, Lars [mailto:L.Svensson@dnb.de] 
> Sent: Wednesday, May 06, 2015 9:36 AM
> To: Simon.Cox@csiro.au; Kerry.Taylor@csiro.au; public-sdw-wg@w3.org
> Subject: 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…).
>  
> [1] https://www.w3.org/2015/spatial/wiki/Glossary_of_terms
>  
> Best,
>  
> Lars
> From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] 
> Sent: Tuesday, May 05, 2015 5:46 AM
> To: Kerry.Taylor@csiro.au; public-sdw-wg@w3.org
> 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: 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
>  
>  
>  
> 
> 
> -- 
> Dr. Peter Baumann
>  - Professor of Computer Science, Jacobs University Bremen
>    www.faculty.jacobs-university.de/pbaumann
>    mail: p.baumann@jacobs-university.de
>    tel: +49-421-200-3178, fax: +49-421-200-493178
>  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>    www.rasdaman.com, mail: baumann@rasdaman.com
>    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>  
>  

Received on Wednesday, 6 May 2015 12:47:19 UTC