Re: [ontolog-forum] Plural taxonomies?

[Deborah MacPherson <debmacp@xxxxxxxxx>]

Hi Mike

 

Faceted classification is a big plus of Omniclass. It allows something like a brick to be the brick itself, part of a wall assembly, part of a hospital, from a manufacturer in Ohio. Hospitals can also be made of other kinds of wall assemblies so there are no straight lines or consistent elements for every project or building type.

 

It would only be possible to "build a single taxonomy for a given application, based on a single facet" - being able to go from bricks to every type of building that could be made this way - if a large percentage of all possible end points and combinations was known. For formulaic buildings like college dorms maybe this could be done. But industry wide, due to all the slang (like Over the Counter) and proprietary manufacturers terms, it is not  possible for each term used within the industry to modeled semantically. Maybe all that can be done is to model basic terms can be used outside our domain, such as financial and emergency management, that don't get as wrapped up in technical detail or brand names. Other classification systems, like UniFormat, are used to price buildings which can help technical details end up in the right generic buckets.

 

It makes sense to me that "things" could be basic classifications in typical groups (brick hospital building) but there needs to be another reliable layer to consistently process facts - the brick wall is 3 stories high, built 10 years ago, 80 percent are openings.

 

For NIEM, OWL is used which may help with -  "In OWL there are classes (with the super-class of owl:Thing), and two types or properties, Object Properties and Datatype Properties. We refer to the OWL Classes as "Things" and properties as "Facts" namely "Relationship Facts" and "Simple Facts" respectively."

 

Omniclass also has a Properties table for "3 stories high" material strength and so forth. Having Object Properties classified will be useful to architects, engineers, software developers, manufacturers, online libraries.  The Datatype properties may be useful for composing messages from some BIM data, some GIS, some SensorML, some EDXL. The IEM spec with the definition is slightly similar between "nature" = datatype and "purpose" = things, facts, and relationships.

 

If taxonomy is taken away to avoid being circular, and get plural and singular to agree, and because we do need to deal with both data elements and real world entities -

 

"A conceptual model that represents relationships and rules among exchange specific entities."

 

Regards,

 

Deborah

On Mon, May 31, 2010 at 3:16 PM, Mike Bennett <mbennett@xxxxxxxxxxxxxxx> wrote:

Hi Deborah,

Thanks for the pointer to Omniclass, it looks interesting. It looks as
though you are dealing with the same issues we are dealing with in the
financial securities industry. The industry recognises the need to
define terms globally across a whole industry, and as such those terms
are a superset of what you would find within a single application's data
model. People in different parts of our industry use the same words in
different ways, for instance we have "Over the Counter" as a means to
sell debt securities, which are essentially contracts that can be bought
and sold, but derivatives traders use the term "Over the Counter" to
signify bilateral contracts between two parties (struck, rather than
traded, over the counter), and are often not aware of the other usage.
The ontology gives context to the term, so that it should be clear from
looking at the diagram, whether it is a diagram of a kind of bilateral
contract or not.

There is an interesting by-product of this. In order to have a model in
which each term used within the industry is modeled semantically, we
have a taxonomy with multiple inheritance, but for any one application
the data model of that application would be constrained to have a single
inheritance taxonomy. As an example, securities traders would be
intersted in the cashflow of securities since this directly affects the
cashflow of their portfolio, so they would classify things in terms of
fixed v floating interest and amortizing versus "Bullet" (single
payment) principal repayment. Meanwhile a risk management application in
the "Middle office" would be more interested in the issuer and / or the
collateralization of a security.

Here's where it gets interesting: it should be possible to formally
identify the different facets by which sub-classes of a class of thing,
as "Classification Facets" (my term, but it might catch on). What if one
could write a program that could parse those classification facet
indications, and build a single taxonomy for a given application, based
on a single facet? Then one ontology can be used to formally specify
interoperable and meaningful terms across the enterprise. The
alternative, which I suspect goes on, is when people apply the
limitations of the technology onto the ontology, which of course is
right if one is documenting the ontology of a single, existing
application, but offers no new benefits to the enterprise other than
better application documentation. Since an ontology sits at the level of
"Business Conceptual Model" in the Zachman Framework and other
development frameworks, it should of course not reflect any technical
design limitations.

In terms of your definition, I would suggest that including taxonomy in
the definition makes it circular. I would adapt Schwartz's definition to
say something like "A taxonomy is a structure which models concepts in a
domain from abstract to specific". I would also lose the word "Data"
since both a data model and a conceptual business model may embody a
taxonomy (one being of data elements, the other of real world entities).

Cheers,

Mike

Deborah MacPherson wrote:
> Hi Mike
>
> Thanks for this explanation. Your statements could apply to this

> situation because of Omniclass <http://www.omniclass.org/>, a

> multi-faceted classification strategy for the built environment.
> Omniclass includes facility types, space types, properties,
> organizational roles etc. in 15 related tables. Any object in the
> built environment could be classified and processed any number of
> different ways on multiple levels, using Building Information Modeling
> (BIM) parameters, which some BIM vendors are beginning to support.
> When BIM or CAD data needs to work within exchange models, with
> pre-defined taxonomies like NIEM, an ideal ability would be setting up
> exchanges and processing not only BIM parameters but also Geographic
> Information Systems (GIS), financial data, regional and weather data,
> health and human services, public safety - a huge assortment of
> natural and man made activities that can be tied to specific buildings
> and building types (ie hospitals).
>
> Based on your feedback, perhaps the definition could be +/-
>
> "A conceptual data model that represents relationships and rules
> among nodes in a polyhierarchical taxonomy."
>
> Or, considering the suggestions from Alex S. and Chris M could be
> simplified further
>
> "A conceptual data model that represents relationships and rules among
> entities in exchange specific taxonomies."
>
> Maybe something like that. Thanks also David E for your comments. To
> some extent data about buildings and infrastructure does need
> handle terms having multiple meanings, more often though it is the
> opposite where multiple terms have the same meaning.  There is a lot
> of slang for example "drywall" versus "gypsum board".  Also the issue
> of translating between with different natural languages - on the
> simpler side English and French for projects in Canada, on the larger
> side for the International Framework for Dictionaries

> <http://dev.ifd-library.org/index.php/Ifd:IFD_in_a_Nutshell> (IFD)

> which software developers should be able to use for many purposes.
>
> Another problem is a consistent, reliable method for getting back to
> the simplest version of a term for exchanges. For example architects
> and engineers could spend a lot of time determining the exact
> requirements for a concrete mix or structural steel - project specific
> properties. By the time that information gets to the point of
> specifications and real world testing results - BIMs and construction
> documents can lose sight of the fact a project-specific material needs
> to revert to a generic, non-technical description for first responders
> as simply "concrete" or "steel". Where it really gets complex is
> trying to apply multi-faceted classification to the IFD to serve the
> detailed needs of architects, engineers, software developers and data
> modelers - but also the general needs of cost estimators, fire
> departments, insurance agencies that only need 1 or 2 high levels to
> be consistent across the entire spectrum of potential exchanges.
>
> So - relationships and rules among entities in exchange
> specific taxonomies - might work
>
> Thanks again
>
> Deborah
>
> On Mon, May 31, 2010 at 10:23 AM, Mike Bennett

> <mbennett@xxxxxxxxxxxxxxx <mailto:mbennett@xxxxxxxxxxxxxxx>> wrote:
>
>     I tend to start from the definition given in Schwartz 2005
>     http://homepages.cwi.nl/~media/publications/masterthesis_kat_domainmodel_2005.pdf

>     <http://homepages.cwi.nl/%7Emedia/publications/masterthesis_kat_domainmodel_2005.pdf>

>
>     "A taxonomy is essentially a hierarchical tree structure which
>     models a
>     domain from abstract to specific."
>
>     However, she goes on to say that a taxonomy "should" not be
>     polyhierarchical, which may be good advice for an individual
>     application
>     but I think supports the wider definition of a taxonomy as any set of
>     terms disposed according to transitive "Is A" relationships. So as
>     such
>     I think her definition is too specific.
>
>     Many developers take the technical (or common sense) limitation of
>     single hierarchy and assume that this must apply to taxonomies
>     generally. I don't go along with this. Some taxonomies (like Linnaeus)
>     are by definition monohierarchical because they classify entities
>     according to one classification facet alone. Others like the ISO 10962
>     Classification of Financial Securities fall down precisely because
>     they
>     try to shoehorn entities into a single hierarchy while classifying
>     them
>     according to more than one classification criterion. In the EDM
>     Council
>     semantics repository ontology, we have built the model around a
>     polyhierarchical taxonomy, in order to formally model each of the
>     terms
>     that is considered meaningful in the industry. One thing I am
>     looking at
>     for a future version is to formally identify the classification
>     criteria
>     against which each sub-set of something is defined. For example debt
>     instruments are frequently classified according to their issuer types
>     (Corporate, Sovereign, Municipal) and separately against their
>     cashflow
>     behaviour (fixed, floating etc.) and these are all meaningful. One
>     would
>     expect any individual data application to base its data model around
>     only one of those classification facets.
>
>     So my advice would be to describe something as "a" taxonomy in the
>     singular if it contains a single coherent sest of entities disposed
>     according to "Is A" relationships, whether that taxonomy is
>     monohierarchical or polyhierarchical. That I think would be the
>     simplest
>     descriptive framework around which to dicuss the nature of any given
>     taxonomy. I've started to standardise on the term "Classification
>     Facet"
>     for the different monohierarchical sets of content within that, and I
>     think others are converging on similar terms but I'm open to ideas.
>
>     Also note that this usage supports the creation and description of
>     taxonomies which are themselves partitioned according to a lattice
>     such
>     as the KR Lattice, since one taxonomy may have e.g. Independent,
>     Relative, Mediating as well as Continuant v occurrent at the top level
>     with "Thing" above that and multiply classified intersections below
>     (classifying something as a Continuant Independent etc.). Though one
>     could describe as a taxonomy any coherent sub-set of that whole, for
>     instance a taxonomy of types of contract.
>
>     Mike
>
>     Deborah MacPherson wrote:
>     >
>     > Dear Ontolog Forum
>     >
>     >
>     >
>     > Since last July I've been talking with the National Information
>     > Exchange Model (NIEM) Business Architecture Committee (NBAC) about
>     > facilities information, and looking at NIEM documentation in more
>     > detail to figure out what needs to be done with facility classes and
>     > xml schemas for re-use outside the building industry.
>      Currently, NBAC
>     > is looking at the upcoming Information Exchange Model (IEM)
>     > Specification. An appendix lists definitions for IEM Artifacts, the
>     > following definition is used for Ontology
>     >
>     >
>     >
>     > "A conceptual data model that represents relationships and rules
>     among
>     > nodes in taxonomy"
>     >
>     >
>     >
>     > Please temporarily disregard previous conversations on this forum
>     > about appropriate definitions for ontology - this seems to be OK for
>     > purposes of this exchange model - even if it may not be correct for
>     > other purposes. However, grammatically there seems to be a problem
>     > with what is singular and what is plural
>     >
>     >
>     >
>     > ·         A conceptual data model
>     >
>     > ·         represents
>     >
>     > ·         relationships and rules
>     >
>     > ·         nodes
>     >
>     > ·         taxonomy
>     >
>     >
>     >
>     > My inclination is this should say "a" taxonomy. But that is why I'm
>     > writing, would it be more conceptually and technically correct
>     to say
>     > "multiple" or "related" or "a set of" taxonomies? Feedback would be
>     > appreciated on exactly how this short definition should be written
>     > accurately. Also, the definition does need to stay very short
>     >
>     >
>     > Thank you
>     >
>     >
>     >
>     > Deborah MacPherson
>     >
>     >
>     >
>     > --
>     > ********************************************************
>     >
>     > Deborah L. MacPherson CSI CCS, AIA
>     > Specifications and Research Cannon Design
>     > Projects Director, Accuracy&Aesthetics
>     >
>     > ********************************************************
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     > _________________________________________________________________
>     > Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>     > Config Subscr:
>     http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>     > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>     <mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx>
>     > Shared Files: http://ontolog.cim3.net/file/
>     > Community Wiki: http://ontolog.cim3.net/wiki/
>     > To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>     > To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>     <mailto:ontolog-forum@xxxxxxxxxxxxxxxx>
>     >
>
>
>     --
>     Mike Bennett
>     Director
>     Hypercube Ltd.
>     89 Worship Street
>     London EC2A 2BF
>     Tel: +44 (0) 20 7917 9522
>     Mob: +44 (0) 7721 420 730

>     www.hypercube.co.uk <http://www.hypercube.co.uk>

>     Registered in England and Wales No. 2461068
>
>
>     _________________________________________________________________
>     Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>     Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>     Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx

>     <mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx>
>     Shared Files: http://ontolog.cim3.net/file/
>     Community Wiki: http://ontolog.cim3.net/wiki/
>     To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>     To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx

>     <mailto:ontolog-forum@xxxxxxxxxxxxxxxx>
>
>
>
>
> --
> ********************************************************
>
> Deborah L. MacPherson CSI CCS, AIA
> Specifications and Research Cannon Design
> Projects Director, Accuracy&Aesthetics
>
> ********************************************************
> ------------------------------------------------------------------------
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>


--
Mike Bennett
Director
Hypercube Ltd.
89 Worship Street
London EC2A 2BF
Tel: +44 (0) 20 7917 9522
Mob: +44 (0) 7721 420 730
www.hypercube.co.uk
Registered in England and Wales No. 2461068


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx

-- 
********************************************************

Deborah L. MacPherson CSI CCS, AIA
Specifications and Research Cannon Design
Projects Director, Accuracy&Aesthetics

********************************************************
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)