Re: a "standard" = a defensible instructional precedent [was] RE: EM Standards List

Craig -

Interesting perspective and I do not necessarily disagree with your concept.

However, should this group use cycles to define a new taxonomy for 
"standards"? Why not just use currently agreed to international best 
practice as to what a standard is and how standards bodies are already 
characterized. For example, ISO and the ITU are de-jure international 
standards organizations. The OGC, OASIS, W3C are what are termed voluntary 
consensus standards organizations. In all of these organzations, there are 
well defined legally approved processes, IPR policies, and so forth designed 
to insure an open process (within the rules of membership), consensus, and 
balance of interest that result in open standards.

So, I would suggest for each standard that there be a note as to its 
provenance. There should also be a a note on implementation in the market 
place. I agree that a standard that has not been implemented is probably 
pretty useless.

Cheers

Carl

----- Original Message ----- 
From: "C H" <craighubleyca@yahoo.com>
To: <donc@internode.on.net>; <public-xg-eiif@w3.org>; 
<public-xg-eiif-request@w3.org>
Cc: <humanitarian-ict@yahoogroups.com>
Sent: Saturday, February 23, 2008 1:11 PM
Subject: a "standard" = a defensible instructional precedent [was] RE: EM 
Standards List


>
> I find the word "standard" problematic.  In general I
> don't use it.  The more operational way to describe a
> so-called standard is as a set of instructions (such
> as a vocabulary or ontology) that may be used as a
> design precedent, independent of who or what advocates
> using or following them.  Many "standards" are de
> facto and poorly documented or documented only in the
> manuals of widely used proprietary systems.  Copying
> such instructions around as design precedents can be
> as complex as the integration of prior case law in a
> legal defense.  It doesn't pay to oversimplify this.
>
> You have five different processes going on at least:
>
> 1. An effort to characterize and consider prior
> instructions as precedent for future design choices,
> such as creating categories and tables of "standards".
>
> 2. A subsequent defense of those choices that will in
> general involve reference to their status as standards
> or precedents or constraints or interoperability needs
> or whatever other words one wants to use.
>
> 3. Attempts to influence or direct the improvement of
> either or both processes, with reference to economics
> of capital asset management, time management, and
> etc., arguing that "it's worth" or "not worth" doing.
>
> 4. Actual use by practitioners in the field.
>
> 5. Integration of field feedback regarding deployed
> real world systems, which of course can only exist if
> the system is actually deployed.  A good reason to
> favour actually deployed systems as design precedents.
> ;-)
>
> 6. More factional and political processes including
> attempts to accredit or discredit particular people,
> institutions, instructions, for particular purposes.
>
> Here's a minimal one-page start to dealing with 1 to 3
> sanely so as not to derail or bias 4 to 6:
>
> Capital assets that many people call "intangible" can
> easily and uncontroversially be categorized as the
> human "individual" (real actual non-corporate persons
> with bodies that eventually die), the "instructional"
> (made out of bits) and "social" (made out of
> relationships between living beings, and not reducible
> to any sequence of bits or individual body).  Flesh
> this list out with "financial", "natural" or
> ecological, "infrastructural" or physical or
> manufactured, styles of capital as required.  There
> are only those six in my opinion, and that opinion
> came from much research.
>
> Orthogonal to the capital asset type, one describes
> the authority or process by which they are defensible
> for inclusion in particular works or projects.  For
> that I create a broad category called "defensible" and
> make the UN agencies, IEEE, ANSI, ITU, and other
> non-institutional sources of such instructions
> including widespread use in certain industries a
> subcategory of "defensible", i.e. "defensible in Don's
> home state due to widespread use in Fire Brigades" is
> just another subclass of this "defensible" category.
> Without having to invent a bizarre tangle of virtual
> authorities and pseudo-institutions just to fit into
> some incorrect model that standards necessarily arise
> from institutions.  Similarly, "defensible with
> reference to Heidegger's claim that language comes at
> us from the future" is just another subcategory of
> defensible and can co-exist with any other rationale
> one might need to invoke in a design argument.
>
> These are strictly operational definitions and will
> save a lot of trouble compared to baroque structural
> category systems that make indefensible assumptions.
>
> For the benefit of those who wish to defend the above:
>
> I submit that any fool can tell a living body from a
> sequence of bits from a social relationship between
> living things.  And that anyone qualified to become
> involved in a design argument recognizes such a wide
> range of defensible design constraints that there's
> more lost than gained in trying to pigeonhole all of
> them in advance.  If it turns out that 90 per cent of
> the design arguments are resolved by referring to one
> of the accredited standards bodies, fine, you might
> wish to create a subcategory for such bodies and then
> invest in arguing what "accredited" means.  But there
> would still be that 10 per cent resolved by some other
> means, and they'd remain in the catch-all
> "defensible".
>
> And, further, you can describe something as being in
> principle defensible without having to agree with it
> or appear to advocate it.  So someone is unlikely to
> throw around the fact that you added it to a table or
> wiki category, representing it as an actual defense of
> that design precedent.
>
> So that's my defense of the concept of defensibility
> and why I prefer to avoid "standard", "accredited" or
> any implication that institutions authorize
> precedents.
>
> As Don implies, it's often saner to assume that use in
> real world deployed applications is what makes design
> precedents worth considering/copying in future
> designs.
>
> Craig Hubley
>
> --- "donc@internode.on.net" <donc@internode.on.net>
> wrote:
>> Hi Renato, all,
>>
>> Great to see this project kick-off.
>>
>> Just a thought - We may need to consider what we
>> mean by
>> 'standard' when referencing works and developments.
>> A
>> standard may be under development, promoted,
>> implied,
>> adopted and/or ratified. A standard may not be 'the'
>> standard beyond a certain group (i.e. Firezone is
>> the
>> standard emergency information and communications
>> interface
>> used by 2,600 Fire Brigades and more than 70,000
>> response
>> personnel in my home state. The contained language
>> is
>> arguably more of an adopted standard than some
>> others
>> promoted by simple virtue of use and coverage. I
>> think we
>> may need to acknowledge where and by whom certain
>> standards
>> are accepted and applied). There are many such
>> industry and
>> emergency sector-specific standards to consider, as
>> there
>> are standards ratifying authorities.
>>
>> I would also like to support Gavin's suggestion re
>> the
>> importance of understanding and incorporating
>> affiliated
>> (and sometimes legislatively superior) standards to
>> this
>> initiative, and acknowledge that many are under
>> development.
>> Eg. Prof David Cliff (QLD University) is currently
>> leading
>> an ACARP funded project to improve the way
>> information is
>> collected and communicated in mine and associated
>> emergencies (if agreeable I will invite Professor
>> Cliff to
>> join this group).
>>
>> Please find listed below a few of the relevant
>> standards
>> available through the International Standards
>> Association
>> and SAI Global (ISO's etc.).
>>
>> IEEE 1512:2006
>> Common Incident Management Message Sets for Use by
>> Emergency
>> Management Centres
>>
>> ISO/IEC 19763-1:2007
>> Information technology - Metamodel framework for
>> interoperability (MFI)
>>
>> TR 102 444 V1.1.1 (2006) : Emergency Communications
>> (EMTEL);
>> Analysis of the Short Message Service (SMS) and Cell
>> Broadcast Service (CBS) for Emergency Messaging
>> applications; Emergency Messaging; SMS and CBS
>>
>> TS 102 181 V1.1.1 (2005)
>> Emergency Communications (EMTEL); Requirements for
>> communication between authorities/organizations
>> during
>> emergencies
>>
>> INCITS/ISO/IEC 11179-2-1999 (R2005)
>> Information Technology - Specification and
>> Standardization
>> of Data Elements - Part 2: Classification for Data
>> Elements
>> (formerly ANSI/ISO/IEC 11179-2:1999)
>>
>> SR 002 180 V1.1.1 (2003)
>> Emergency communications Requirements for
>> communication of
>> citizens with authorities/organizations in case of
>> distress
>> (emergency call handling)
>>
>> ANSI INCITS 415-2006
>> Homeland Security Mapping Standard - Point Symbology
>> for
>> Emergency Management
>>
>> SR 002 299 V1.1.1 (2004)
>> Emergency Communications; Collection of European
>> Regulatory
>> principles
>>
>> TS 102 424 V1.1.1 (2005)
>> Telecommunications and Internet converged Services
>> and
>> Protocols for Advanced Networking (TISPAN);
>> Requirements of
>> the NGN network to support Emergency Communication
>> from
>> Citizen to Authority
>>
>> Best regards,
>>
>> Don Cameron
>>
>>
>
>
>
> 
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search. 
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>

Received on Saturday, 23 February 2008 22:48:24 UTC