ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Architectural considerations in Ontology Development

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Hans Polzer" <hpolzer@xxxxxxxxxxx>
Date: Fri, 22 Feb 2013 16:47:25 -0500
Message-id: <022001ce1146$3462b4b0$9d281e10$@verizon.net>

Kingsley,

 

I’d say that it is often a bad thing to have apps as data silo vectors, especially if it is the only way to get at the data (which is what I assume you mean). But one has to remember that most data stores don’t explicitly represent their own context and scope, other than haphazard attempts at capturing these in the name of the data store, or possibly some data element names. The apps (or web services) can serve as context and scope representations and mediators via their user interface or web service  request parameters. I’m reminded of a talk by a NASA software engineer that I attended a few years ago on their spatial data management web services architecture. One of the service request parameters was “planet”, although it probably should have been something more like “celestial object”. 

 

I’ve also had other experiences with outside organizations attempting to access our data stores without really understanding the schema and underlying business rules (like what a “stop” oriented transportation data model implied for determining inventory state vice a “leg” oriented model used by some of the data providers) – and then complaining that their query results were incorrect or misleading. Hiding the schema complexities behind a few simple web services solved this problem – but still made the data accessible to authorized users without requiring them to use a specific user interface app.

 

Hans

 

From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Kingsley Idehen
Sent: Friday, February 22, 2013 4:22 PM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Architectural considerations in Ontology Development

 

On 2/22/13 3:24 PM, Barkmeyer, Edward J wrote:

Kingsley Idehen wrote:

 

> Sadly, monolithic applications too often dominate the focal points of decision

> makers and developers.

 

I'm not sure that is "sad".  In most organizations that is vastly better than separate systems for separate fiefdoms, and the uneducated judgment of some manager that he can do in ExCel what the company bought a financial system for.


I mean: it's a bad thing to have apps as data silo vectors.


 

> It's so bad that individuals and enterprises are

> (today) purchasing computing devices en masse for which (as owners) they

> don't even posses 'root' privileges.

 

I think this means that corporations acquire and install lots of computers for workers who lack the privileges to do system administration.  And that is certainly as it should be, because (a) these people don't have the specialized knowledge to do it, and (b) they should not have the need to do it.  Unfortunately, the providers of much of the packaged software have not grasped this fact -- they have tried to automate installation and update processes so that the user doesn't need the systems management skills, but assume that the user has the privileges he lacks the skill to use wisely.  (In part, this is a consequence of the system requirements for implementing the "Windows look and feel".)


I am referring to the fact that organizations and people are acquiring iOS5 tablets and phones for which they don't have 'root' access.


 

> Saddest of all, programmers now totally dominate dialog about computing.

 

In some geek forums, perhaps, but that is an insignificant part of the dialog.


I think most of the Web dialog is dominated by programmer thinking. I like this forum because it's one of the few places where conceptualization and modelling are key topic drivers.


The local real estate agents and the nurses in the hospital and the used car dealers are quite able to talk about the computer systems they use in their daily work, and they are not programmers.  And the managers who chose and bought those systems are not programmers and don't talk with them.


Correct, because (and this is a long story, so I am giving the short answer) they've abdicated the prime role of actually taking data literacy seriously. Computing is all about data processing, as you know :-)


The programmers are a handful of elves in the woods who have little influence on any decisions about corporate computing.


Not so since the advent of the Open Source era. An unintended consequence, so to speak.


They just get the job of installing the chosen products and making nice screen views for upper management.


Pre Web, maybe, In my experience these days -- it's all about code first and programming language oriented religious wars.


 

And OBTW, this is a good thing.  Computers in business and industry are tools, and they are (finally) considered to be tools, not hobby kits.


Yes, but the hobbyists are now the enterprise developer + architect of yore. Sadly, the are rarely good at real programming and non starters when it comes to architecture.


  As Steve Fenves, a former Mechanical Engineering chair at CMU, observed, "we are finally teaching engineers how to use computers instead of how to program computers".


I wish that was my experience. That's exactly how it should be, but not what I come across in my travels, unfortunately .


 

> What happened to systems analysts, database designers, ontologists etc?

 

They are well paid consultants or "marketing support" staff for software houses.  The in-house analysts in industry now have different titles: Enterprise Systems Coordinator, and the like.  For the most part, their job is to configure or modify an off-the-shelf model into one suitable for supporting their operational practices.  Many "systems analysts" are now called "business analysts" or "enterprise analysts", because their job is to figure out how the organization works, what needs to change, and how best to support the target operations practices with mostly off-the-shelf software systems.  Even big companies have spun off most of their software shops, because they are not core competencies and they rarely provide more than indirect support for revenue producing processes.  A lot more attention is paid to the source and quality of software that directly implements revenue producing processes, like operations scheduling, equipment control and online purchasing.  And that requires specialized knowledge and skills, which is better purchased from a reliable contractor.  IMO, this is as it should be.  Shell Oil doesn't build pumps, Tokyo Electric doesn't make turbines, hospitals don't make dialysis machines.  Why should they build software systems?


That's how  it should be, but  the folks you describe  aren't part of the major dialogs that occur on the Web, certainly not in the quarters that I frequent.

 

> I believe applications are like fish and data like wine. The world (in the

> majority) still doesn't understand what data actually is, let alone the

> fundamental implications of such dangerous ignorance :-(

 

I agree 100%.  But that has been so for 50 years. 


Yes, but we have the eexponential effects kicking in these days. Thus, really bad stuff ends up affect a lot of people etc..


The main failing of the period from 1960-1995 was trying to understand a problem space in terms of an implementation paradigm.


Yes!


Today fewer analysts are being asked to design a solution, because the company intends to buy the solution, or at least the major building blocks. 


I wish the ccompanies thought in terms of "blocks" as that would certainly reduce the problem I am gripping about.


What they want the analyst to do is document the real requirements for the capture, archive and delivery of information.  They understand "data" as the information they will use and how they will use it, rather than what the system will do to/with it.  And that is a major step forward.


Yes, but still not the dominant case I experience though :-(

Kingsley

 

-Ed

 

 

--

Edward J. Barkmeyer                     Email: edbark@xxxxxxxx

National Institute of Standards & Technology

Systems Integration Division

100 Bureau Drive, Stop 8263             Work:   +1 301-975-3528

Gaithersburg, MD 20899-8263             Mobile: +1 240-672-5800

 

"The opinions expressed above do not reflect consensus of NIST,

and have not been reviewed by any Government authority."

 

 

 

 

>

> --

>

> Regards,

>

> Kingsley Idehen

> Founder & CEO

> OpenLink Software

> Twitter/Identi.ca handle: @kidehen

>

>

>

>

 

 




 
_________________________________________________________________
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
 




-- 
 
Regards,
 
Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
 
 
 
 

_________________________________________________________________
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    (01)

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