[Top] [All Lists]

Re: [ontolog-forum] Difference between XML and OWL

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Mike Bennett <mbennett@xxxxxxxxxxxxxxx>
Date: Fri, 07 Nov 2008 18:52:05 +0000
Message-id: <49148E55.1010900@xxxxxxxxxxxxxxx>
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:
> Mike,
> 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 
solutions hereabouts).
> 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
> strength.
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)

> John
> _________________________________________________________________
> 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
>       (012)

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    (013)

<Prev in Thread] Current Thread [Next in Thread>