Semantic Data Layer for Programming

Semantic data semantic layer for software development
could software development become easier if we could build a data semantic layer on top of databases?
what if we could build a data semantic layer on top of logical constructs?
not just reports but a data semantic layer adjusted for the terms that programmers want to see
not just the terms that businesses want to see
this could be an object member semantic layer

Action Verbs to Think Up Level 3 Project Ideas

This list covers action verbs to think about information in order to create new project ideas. Note that ‘negate’ gets used with other action verbs like ‘hurt’; note that these verbs may be combined.

• Advocate: sell/promote
• Benefit: help/improve
• Create: Build/Develop/Construct
• Decision: Decision Making/Choice/Action
• Effect: Event/Result/Output/end/finish
• Future: planning/prediction
• Govern: manage/handle/guide/control
• Hurt: damage/problem/hazard
• Individualize: Customize/User preference
• Joined: Relationships/interaction
• Keep: settle/fix/be
• Location: physical world
• Modify: change/alter
• Negate X: avoidance/nullification/Negation
• Optimize: Balancing/Resources
• Presentation: Present/Format/Arrange/Layout
• Quanta/data: Data/text/numbers/bits/files/documents/measurements/values
• Receive: Get
• Send: Put/publish
• Technology: Integration/Technology/Interfaces/UIs
• Understand: Learning/Understanding/Knowledge building
• View: Vision/Recognition/spotting/finding/searching/detection

Projects that Can Do Using Information Early

Some example projects that could be built using Level 3:

• Attention management: email, social media, texting, collaboration, advertising – a system that will manage these based on user attention desires.
• Automated invention: come up with invention ideas using an automated system.
• Capital expenditure allocation: build an application to identify where capital need to be expended, which areas, which technologies, which capabilities are needed.
• Compassion profiling: find where each employee belongs in an organization based on talent, skill, and attitude.
• Complex dynamic line of business transaction management: build information model(s) to cover the various workflows that a business may need to use in the future and use the models to control all workflow in an application.
• Complex inventory flow management: build information model(s) to cover the various states that a piece of inventory could be in.
• Complex page level security management: build an information model and use it on each page, for each data ‘section’, for each user/customer, and for each resource/function.
• Data finder / deep web search engine: build a web search engine based on information models. Select as a niche, sites that cover statistical information, databases, large text files, data files, the deep web etc.
• Extract legacy application value for migration: extract information from a legacy application for use in developing replacement apps. Build information models embedded in the logic of the legacy application.
• Fill holes in a team talent set: identifying gaps in a team’s talent set by identifying each member’s talent, skill, and attitude and using this to prioritize task assignments, and using this to identify what is missing for hiring purposes, and identifying how well each candidate fills those gaps.
• Finding the right talent: build an application for hiring – identify talent through word-level resume analysis, blog analysis, social media analysis, forum postings. Build a dictionary of word to talent translations.
• Global niche economics: project collaboration, attention management, information model collaboration, cloud existence, production, design, distribution, customer involvement, parts and software, micro-finance, attention scoping.
• Glomming database types: database model simplification, type concentration, type centralization, to get the biggest bang for the buck, identify the core complex states.
• HL7 Auto-version: Build an application that can work with any version of HL7 without having to do much application rework.
• Hyper-science: build an application to convert scientific concepts into information form, then use this to do attention management with the scientific community.
• Implicit geometry: a technology to compete with and collaborate with polygons, fuzzy information for content, recognition for interactions, generators for display, models for shaping.
• Individualized marketing documents: generating individually targeted marketing documentation based on 1)customer input, 2)customer search patterns, 3)customer purchasing patterns.
• Internal organization information finder: Characterize each document in an organization using information model(s). Use these to find information, coalesce information, find information gaps.
• Knowledge based CMS: build a CMS system which provides metadata as part of its knowledge base.
• Mergers and acquisitions: what functionality is duplicated and what functionality needs to be or can be extracted for use.
• Simplify AI: Simplify AI heuristics through recognition of fuzzy states.
• Software capability inventory: identifying which software capabilities you already have and which you need.
• User aligned data entry: Build user interfaces that can handle 0nf entries.
• Using the results of data mining: Scrape the results of BI, data mining, and data analytics into an active information models. Then use them to power applications.
• Venture capital allocation: which projects deserve more support and which less.

Examples of information when used inside an application

Here are some examples of capabilities that using information provides for a program when used inside an application:

• Allocation: Balancing/distribution/Balancing/resource allocation
• Building AI: Knowledge representation/AI/Data–>Information–>Ontologies->AI.
• Context/metadata: Metadata/Context/Richer metadata.
• Defined data: characterized data/data context/semantic data/soft coded context.
• Evolving systems: Evolution/Genetic Algorithms/Genetic algorithms.
• Fuzzy information: Anti-aliasing data and information.
• Generators: Creation/Creating new things programmatically.
• Handling 0nf: automation/Conflated information handling (0NF).
• Importance/order: Ordering/Importance management/Prioritization.
• Judgment: Action/decision/function/Decision automation.
• Knowledge/Information: Core information functionality above the level of data.
• Languages: Natural language/sub-natural languages.
• Mutual languages for users/humans/computers, HCI creative partnering.
• Networking: Mutual languages for data networking.
• Overlooked possibilities: Thorough coverage/Overlooked possibility identification.
• Information proxies: Information data equivalent/Proxy creation and analysis.
• Query/search: Filtering/search/matching/Filtering, searching, and matching.
• Recognition: Viewing/recognizing/profiles, signature/pattern recognition.
• State management: Status/State/Situation information, complex state management
• Type assimilation: Kinds/bits/assimilating database complexity.
• Using the results of data mining/information persistence/Information storage.
• Viewing systems: Condensing data/sparse data or information UIs.

Breaking Through the Glass Ceiling in Software Development

This is in response to a question asked on Fora Is there a “ceiling” in software engineering? Why?

Software developers hit a glass ceiling because software development itself has hit a glass ceiling. Software development has failed to figure out how to work with information directly inside a computer program. Instead, we work with data rather than information. We have left the information work to the BI, data analytics, data mining, knowledge representation world. This world works with data after the fact to extract information from it.

What if programmers could work with information inside a program? before the fact. The next level of development could be to work with information as well as data inside a program. The glass ceiling is that we generally can not work with information. An entire new industry development effort needs to get started developing tools and techniques for doing this. I am doing my little bit to break through this glass ceiling at my blog. I also provide libraries for the techniques so far developed. But we need much more than a few techniques that one software developer can create, God willing. We need an industry push to break through the glass ceiling and build the entire information level of software development. Let’s get started!

Each Level Has its Own Native Structure

I will start with an example.

Here are examples at each level to handle a user-customer relationship:

1. Level 1 – RDB: A join table:
   ——————
   user customers
2. Level 2 – OO: A few classes depending on use and need:
   ——————————————–
   a user table with a customer objects list or a customer id’s list depending
   a customer class
   a user class
   a ‘client’ data structure that contains both objects (references to them)
   a user-customer relationship class
3. Level 3 – IOP: Three endeme sets defining user-customer fields:
   —————————————————–
   a UserIdentity set
   a CustomerIdentity set
   A relationship set
4. Level 4 – KR: Two nodes and a relationship edge:
   ————————————–
   customer node
   user node
   relationship edge

Native Organization Schemes

• Level 1 – RDB – relations
• Level 2 – OO  – hierarchies
• Level 3 – IOP – matching/(or memberships?)
• Level 4 – KR  – graphs

For matching, each piece of data is part of whatever it matches well. For membership, each piece of data is part of multiple things.

The First Three Organization Schemes Are Implemented Through Four Types of Tables:

• data tables   – usually have a large number of rows focused on data
• lookup tables – usually have a smaller amounts of rows focused on data [OO]
• endeme tables – usually have a small number of rows focused on ‘type’ [IOP]
• join tables   – plumbing used to connect data tables to tables in a n to n relationship [RDB]

Given the needs of various part of a project, work with one or more of these for different purposes.

Resulting in These Structures:

• hierarchy – oo is especially good with these [like lookup tables]
• join      – uniquely relational              [join tables]
• search    – generally information oriented   [endeme tables and endeme structures
• data      – everyone works with data to some extent
• graphs    – above the level of database tables?

Then adding two more types of tables:

• Endeme implementation tables – endemes
• Graph implementation tables – knowledge representation

Gellish?

These two new groups of tables implement endeme and knowledge representation structures (information structures) in a database. They generally set somewhat apart within the database in their own little engines.