Hi John, (01)
That kind of makes sense, but I wonder if there is a danger of
conflating the semantics of the development with the semantics of the
problem domain. (02)
I'll try and clarify what I mean below... (03)
John F. Sowa wrote:
> I'm glad that you found this discussion useful.
> MB> I see ontology (OWL or otherwise) as fitting into one specific
> > box in the Zachman Framework.
> Actually, all 30 boxes address different aspects of ontology.
> Each of the six columns focuses on the entities found in response
> to one of the six types of questions: What? How? Where? Who?
> When? Why? The answers to those questions determine what has
> to be represented.
Those would be the what, how, where etc. of the development rather than
the problem domain, wouldn't they? The ZF has one box which is clearly
labelled "semantics" which is where I would expect the problem domain
semantics to go (the meanings of terms like stocks, bonds, people,
employees etc.) (04)
Would it not be blurring the boundaries between the solution and the
problem domain, if you were to try to represent the answers to those
questions in an ontology? I can see that the "Business" row covers
answers from real business people about aspects of the job they do. And
I can see how the rows below this in Columns 1 and 2 correspond to the
structural and behavioural dimensions of a UML model for example, or any
development model. So Zachman takes the well-known concepts of
conceptual, logical and physical models and breaks these into several
useful categories. (05)
If one were to define an ontology of the remaining rows, surely it would
surely be an ontology of the solution, i.e. a full description of all
the facts about that solution?
> Each of the five rows focuses on the perspective from a person
> that plays a different role: planner, owner, designer, builder,
> or subcontractor. The product 6 x 5 = 30 boxes, each of which
> shows one perspective by one type of person on one aspect of
> an information system.
A role in the development of the solution, that is, not a role in the
steady-state operation of the business (as compared with your later
example of nurses etc.).
> Ed criticized the Zachman framework because many people have hyped
> it far beyond its usefulness.
They have. However it's also had a beneficial effect similar to that
with the PRINCE2 project management method, which is that it gives a
formal public name to something which describes what people and firms
should have been doing anyway - at least columns 1 and 2 are basic
text-book development theory. Much of the value I see in it among the
people I work with is I no longer have to explain Development 101 to
them I can just wave at things in those first columns of the ZF. (06)
A lot of technology geeks will not implement or adopt anything that
doesn't have a CV-enhancing name to it. Then when someone comes along
and describes all the features that any competent development engineer
would expect to see and gives it a fancy sounding name, the techies are
all over it. I fear that semantics technology is about to go the same
route, I have already had to listen to techies explaining to me how
their model now has "semantics" and even that they can generate these
"semantics" automatically from their ever-inscrutable model. But I digress. (07)
> And I agree with that criticism.
> But I endorse the basic ideas behind the methodology, which can
> be generalized much further:
> 1. The idea of asking questions to elicit information about
> aspects of a subject domain. This is a very old idea that
> started with Aristotle: each of his 10 categories is an
> answer to one type of question. For any give subject domain,
> each answer represents one significant type of entity.
I must admit I have previously only really looked at the first two
columns since these represent the two well-established aspects of
systems development. I see what you are saying though. What is perhaps
not clear from a Zachman view of the world is the old world / new world
distinction where you document processes and information as they exist
before you carry out a development, and then define a proportion of that
(never 100%) which is to be automated or otherwise improved by
implementing some piece of technology. (08)
Even the thinking on that in the analysis textbooks is a bit dated since
the old world / new world theory tends to assume that you are replacing
a manual process with an automated one, whereas the "old world" may be
an older automated system or raft of systems. I wondered if the "When"
column of the ZF proposes to address this, but I see it decomposes into
processing and control information about the solution. Perhaps a third
dimension is needed?
> 2. The idea of considering an ontology from the perspectives of
> different people who play different roles. For example,
> consider a medical ontology with a focus on the perspectives
> of a patient, a general practitioner, a nurse, specialists in
> different medical fields, a pharmacist, an administrator...
I don't see how those perspectives would map to different columns of the
ZF. Surely one needs to capture perspective in the ontology, as
appropriate for that particular problem domain. Here I guess the Why
column perhaps comes into its own? (09)
In any case these are very distinct roles from those of planner, owner,
designer, builder, or subcontractor.
> What I like most about the Zachman framework is its emphasis on
> the many different ways of viewing a system. But my major
> criticism is that it's only a beginning. The 30 different ways
> are just an inadequate approximation to infinity.
Absolutely. Those same techies who approach Zachman like a new word they
need on their CVs, tend to get a bit fundamentalist about what goes into
each box. For a system with any kind of complex architecture, there
would be several decompositions of design in the System Model for
example, rather than just one. Also people can be a bit fundamentalist
about whether an XML schema is a physical model or the physical
implementation of a physical model such as a UML model with XML schema
stereotypes and datatypes.
> MB> What is unfortunate is that UML is so wedded to OO development
> > that it does not extend naturally into the semantic space and so
> > does not cover the whole of the first two columns.
> Yes. But that is also my criticism of the OWL approach. It is
> also very limited, and the people who promote it don't admit (or
> are not aware) that it is a very highly specialized methodology.
There is also little or no definition about how the higher levels of the
model should be structured. You can make pizza a direct sub-class of
"Thing" and not break any rules, but without some taxonomic hierarchy
you are missing a major contributor of meaning in a model. In any case
OWL is not meanings, it's a language, and the stuff modelled in it can
be more or less meaningful according to how well thought out it is.
However much of the current effort in that area seems to focus on
bottom-up tagging for social networking and knowledge base management,
which leads into difficult problems about how to align different
ontologies (on which we've seen some fascinating demonstrations of
> One reason why I recommend that people consider UML, SQL, and
> various approaches such as Zachman is that they shows that semantics
> is involved with all aspects of meaning. OWL is a one-size-fits-all
> notation that can be useful for what it can do, but the subject is
> much, much broader.
Agreed. There is no reason why terms in a SQL database need not be
meaningful, though of course there will be less meaning if there is more
re-use of terms, which is one good reason to have a separate model of
the semantics which is untouched by design considerations. Also some
formats which are good for design would not be expressive enough to
capture as wide a range of real world meanings as you can do with OWL.
For instance you usually can't do multiple inheritance but you need this
to describe the real world. Also you do not need the "Thing" hierarchy
in a data model, but it gives a major fix on the meanings of things.
> People have apologized for OWL by saying that it is just a beginning.
> That's OK *provided that* somebody tells the OWL users that they are
> only scratching the surface of semantics.
Yes indeed. I would love to see some of the thinking that goes on in
here being taken into account in future development of the standard. For
instance I see I am not the only one taking OWL classes and giving them
UML stereotype-bsaed archetypes (as Bill McCarthy calls them) while
still being OWL and RDF. Which ties in to...
> MB> However, [UML] is extensible.
> Yes. And the idea of bringing together multiple approaches that
> had already proved their usefulness separately was its greatest
Agreed. Its weaknesses was the fundamentalist application of object
technology whereby everything is an object. I have looked out of my
window and I see things in the real world that are not OO objects. OWL
being predicated on set theory defines something which by definition is
not a class as defined in UML. I would like to see UML "loosened up" to
allow the language to formally be extended to include RDF and OWL
constructs, rather than having to be extended via profiles as we have to
do at present. I am sure there are other directions it can be extended
into as well.
> My major complaint about RDF and OWL is that they had not proved
> their usefulness as de facto standards or just widely used tools
> before they became integrated into the SemWeb. That's what I
> meant by saying "May God protect us from proactive standards."
Having worked on a number of ISO standards, I am not sure what is the
worst method for developing a standard. One advantage of OWL today is
that there are starting to be some really good tools. Some of those
tools vendors are being dragged kicking and screaming to the point where
they even present views of the business that the business can validate,
though only because the standard is perceived as being mature enough
that those business folks consider it worth the effort. (010)
Sorry for the wait on this reply, things got busy and I wanted to give
it some serious thought. (011)
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (013)