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
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
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.
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!
I will start with an example.
Here are examples at each level to handle a user-customer relationship:
- Level 1 – RDB: A join table:
- 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
- Level 3 – IOP: Three endeme sets defining user-customer fields:
a UserIdentity set
a CustomerIdentity set
A relationship set
- Level 4 – KR: Two nodes and a 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
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.