RE: A NEW FUNDAMENTALLY DIFFERENT FORMAL MOTION: was RE: SUO: Re: SUO Ballot with 2 Questions
Dear Eric,
See responses below.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
> -----Original Message-----
<snip>
> > > > > imaginable for crafting/engineering or perhaps even merging
> > > components
> > > > > into a large and complex standard (such as an SUO), and
> > > > >
> > > > > WHEREAS, only unified hierarchical bodies such as companies
> > > > > are known to
> > > > > craft/engineer large technical results of quality, and
> > > >
> > > > MW: Well I've worked in standards organisations that
> managed this.
> > >
> > > [ELP] Please tell us more:
> > > What were the standards?
> >
> > MW:1. Integration of Lifecycle data for process plant including oil
> and
> > gas production facilities. It is a data model and reference
> data that
> > should collectively be described as an ontology that was light on
> > axioms.
>
> [ELP] About how many tables/entities/classes and attributes
> did you end
> up with?
MW: There are 201 entity types. The model is highly normalised, around
5th normal form, so there aren't many attributes, they mostly turn into
relationships. There are about 20-30 in the whole model.
> Roughly, how many pieces of "reference data" per
> attribute did
> you specify?
MW: The reference data are instances of the entity types rather than of the
attributes. This again results from the high degree of normalisation. The
full POSC Caesar RDL currently stands at some 50,000 concepts, some 10,000
of these are in the public domain.
> How far did this data go beyond typical data dictionary
> contents?
MW: I don't know what you think is typical of data dictionary content.
The RDL has a full subtype/supertype hierarchy, and can identifies physical
properties/quantities for things and the types of relationship they can
have.
>
>
> >
> > MW: 2. Intergation of Industrial Data for Exchange Access
> and Sharing.
>
> [ELP] Same questions as above.
MW: This is an architecture and methodology, not a data model.
>
> <snip>
>
> > > [ELP] "Standardization"
> > ("http://www.m-w.com/cgi-bin/dictionary";) is not
> > creation. "Standardization" is a transitive verb and therefore
> requires
> > something to be standardized. Wouldn't we agree that the
> thing to be
> > standardized is "practice" - that we are specifying a standard
> practice?
> >
> > MW: Standards can do a number of things. Many certainly do
> standardise
> > practice in the procedure sense. But this is not the only sort.
> Standards
> > can be specifications for products, or just statements of facts. Of
> course
> > I think conforming to a standard usually involves some activity.
>
> [ELP] Right. "practice" wasn't the best word I could have chosen.
>
> >
> > How many years were your draft standards used and proven before
> > declaring them to be standards?
> >
> > MW: In practice it is a multistage process, where you declare a
> "standard"
> > and then people examine it and perhaps do trial
> implementations, raise
> > issues, you respond and produce a new version, and after a
> few cycles,
> > (and many years) with persistence out comes a standard, which people
> > then implement (if they find it useful). People quite often
> implement
> > draft standards, but it has to be on the basis that it is the best
> thing
> > available, and at least better than a blank piece of paper.
>
> [ELP] What you've described sounds quite like what is
> fashionably called
> enterprise data modeling except that your enterprise presumably lacked
> authority over its constituents.
MW: Yes and no. Enterprise data modelling tended to be prescriptive, which
usually lead to its downfall, especially as business requirements changed.
We identified that we needed to take a metaphyscial/ontological approach to
model those things that did not change in a way that could support the
changes that did occur.
MW: The data model is intended to be used by the industry, rather than within
a company, so in that sense we do not have authority over potential users.
This means that the model has to be good and useful - not a bad constraint to
have to live with.
>
> How large of a group did the bulk of the real data modeling?
MW: The data modelling team ended up as 3 people, with some 50-100 in a
reviewing role who would raise issues at the different standardisation stages.
>
> <snip>
>
> > And if such a creation should be allowed to be called a standard is
> yet
> > another question.
> >
> > MW: If you have developed a deliverable in an open international
> forum,
> > where many of the worlds leading experts have had chance to
> comment on
> and
> > help develop the standard, and you have operated the standardisation
> > process
> > diligently, you have earnt the right to call the product a standard.
>
> [ELP] What you are describing is difficult for me to
> distinguish from a
> consortium-based development effort. But every development effort can
> have an API. And every interface is a standard for some group big or
> small.
MW: The only difference is the size of the consortium, with an ISO standard,
the consortium is in essence the planet, where almost anyone has the right
to critique what you are doing.
>
> [ELP] Here are some more questions:
> * Was your group using a relatively long used, well understood data
> modeling approach such as OO or relational via ER diagrams or
> some such?
MW: We used EXPRESS which is standardised entity relationship modelling
language with both a graphical and lexical form. It is similar in power
to the static modelling part of UML.
> * Were there were seasoned tools available for the design work and for
> the utilization of your standard model.
MW: Being an ISO standard, EXPRESS has a number of high quality tools
for model development. Implementation environments for the data model
have also been developed in parallel with the standard and are available
from commercial vendors.
> * Was there an established community of "real" users that stood to
> immediately benefit from sharing data.
MW: Yes. The focus for the standard was the hand over of engineering
desig information for process plant between engineering contractor and
plant operator. However, the models have MUCH wider applicability than
this.
> * Did that community or one of its components explicitly fund your
> standards work.
MW: Yes. My involvement was/is funded explicitly by Shell. There are
several consortia who together have funded other parts of the development.
It wasn't always like that. It started off as a hobby activity.
> * Were there a number of models already produced and used by your
> stakeholders that were already used somewhat for sharing?
MW: No. We take take some work we had done in Shell as a start point
though.
> * Did your stakeholders have something akin to concrete
> success criteria
> - such as being able to decide whether they could share and
> receive the
> type of data contained in their own internal schemas.
MW: You are assuming they had internal schema's documented for their
data ... We have very much been leading the way in trying to show
people what is possible, and how things could be better. Resistance to
change has been a major barrier.
>
>
> Thanks again,
>
> -Eric
>
>
> <snip>
>
>