Re: [ontolog-forum] Data, Silos, Interoperability, and Agility

[Adrian Walker <adriandwalker@xxxxxxxxx>]

Hi All,

Her's a presentation and a live online example  showing an implemented way of addressing the challenges of Data, Silos, Interoperability, and Agility.

      www.reengineeringllc.com/EnergyIndependence1.pdf     (slides 19-29)

      www.reengineeringllc.com/demo_agents/EnergyIndependence1.agent

Apologies if you have seen this before, and thanks for comments.

                                                    -- Adrian
                
Internet Business Logic
Open Apps for Open Data
A Wiki and SOA Endpoint for Apps written in Executable Open Vocabulary English over SQL and RDF
Online at www.reengineeringllc.com  
Shared use is free, and there are no advertisements

Adrian Walker
Reengineering

On Thu, Sep 19, 2013 at 12:17 PM, Barkmeyer, Edward J <edward.barkmeyer@xxxxxxxx> wrote:

Kingsley Idehen wrote (in response to David Eddy):

[DE]

Three questions to ask everyone on staff:

- have you ever lost/not been able to find when needed a file or folder?

- how much training do you have as a catalog librarian?

- how would you like to stand up in front of your peers & explain your folder/file system?

Just because people are dimly aware folder/files are important doesn't mean they do a good job of managing them.

[KI]

All of these problems are handled by incorporating the architecture of the World Wide Web into File and Data Management. Please note, my comment in no way implies World Wide Web access to said artifacts. I am simply expressing the fact that making Files and Data web-like (or webby) is a critical part of the solution.

[EB]
The architecture in question seems to be the "data management" idea of creating indexes to the files, which is the Google method of dealing with the Web, and not accidentally, the approach used by the Google and Microsoft local search helpers for my file system.  It is not clear to me that any "webby" idea in the W3C sense is relevant.  The Semantic Web idea was that you take the time to mark up the data set with fancy key words, which improves the relevance of the search results over the approach of indexing pages, files, documents by statistical use of words and wording patterns.  Then you have a language in which you can say things about the relationships of the keywords that can further improve the search.  All of this depends on people doing the markup and saying the useful things about relationships, which most are too lazy to do or don't know how to do.  That human factor (that the indexed statistical search does not depend on) is the difference in their success rates.

The LOD idea is the HTML idea of intentional links.  I know this is related to that, and I put the reference in the text/data (or maybe in some attached metadata object that has to be constructed with a tool, a la Sem Web).  And instead of the 14 standard bibliographic citation forms, we have one scheme that software can implement directly, and oh yeah, can make indexes for.  The idea of formal citations goes back to the 19th (if not 18th) century, and catalog indexes by keywords attached to the documents (by somebody) has been a staple of library science since the turn of the 20th century.  And I suspect that the idea of authors supplying the keywords (the index basis) as well as the citations (the intentional links) showed up when the volume of printed material exceeded the capabilities of the librarians whose job was to scan the work and create the keywords (like Google).  LOD depends on authors putting in the links, or subsequent librarians building the metadata.

So, as Kingsley has repeatedly pointed out, the real Web technologies are indeed automating proven techniques.  But let us not get confused as to which ones best serve which purposes, given that humans and their behavior patterns will be involved.   There are three basic Webby ideas:  knowledge-assisted (or nearly blind) statistical indexing, explicit links, and explicit metadata.  File systems offer a fourth -- hierarchical collections.  Each has its value.

To go back to the base of this thread, the real reason why we have brittle systems is two-fold:
 - the limitations of current tools and their accessibility to the people who have to do the job, and
 - a lack of clairvoyance as to future requirements, which is only sometimes just short-sightedness.
In 50 years of IT, every new technology just moves the problem.  But along the way, what the tools can do for us NOW has improved greatly.  New technologies are successful if they are both useful and accessible, or useful and work with negligible human interaction.  A technology can only be more or less brittle with respect to ANTICIPATED change.  "Disruptive technologies" are rare.  "Disruptive events" are unfortunately fairly common.  Like the poor, silos and legacies you will have with you always.

-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."

_________________________________________________________________
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

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