Thursday, March 23, 2017

KBE, futures

I wrote this on Wikipedia (Knowledge Based Engineering - KBE futures, KBE theory) back in 2006:
    KBE, as a particular example of KBS, is a multi-disciplinary framework that has more than practical considerations. Not only will KBE require successful handling of issues of the computational (OntologyArtificial IntelligenceEntscheidungsproblemInteractive computationCategory Theory, ...) and logic (non-monotonic issues related to the qualificationframe, and ramification problems)), it will touch upon all sciences that deal with matter, its manipulations, and the related decisions. In a sense, Product Lifecycle Management allows us to have the world as a large laboratory for experimental co-evolution of our knowledge and artificial co-horts. As noted in ACM Communications, "Computers will grow to become scientists in their own right, with intuitions and computational variants of fascination and curiosity." [19] What better framework is there to explore the "increasingly complicated mappings between the human world and the computational"?
    A continuing theme will be resolving the contextual definitions for KBE into a coherent discipline and keeping a handle on managing the necessary quantitative comparisons. One issue considers what limits there may be to the computational; this study requires a multi-disciplinary focus and an understanding of the quasi-empirical. Given the knowledge focus of KBE, another issue involves what limits there might be to a computational basis for knowledge and whether these are overcome with the more advanced types of human-machine interface.
    It is important not to treat the KBE technology in isolation, but focus more on its role in the overall Product Development Process (PDP). During development, it is important to streamline the process from knowledge capture towards software implementation. To this end, close-coupling between Knowledge Management and KBE is desired. Transitions from data and information inside a Knowledge Base towards software code is of particular relevance. The best results can be achieved by using model-driven software development principles, which includes automatic code generation and round-tripping. The use of KBE during a PDP not only requires the ability to easily set-up (existing) KBE applications from a knowledge level, but also the ability to store back the results after execution of the tool. In order to use KBE on a strategical level as decision-making and planning support mechanism, it is important to relate results back to the system engineering domain (requirements, functions, options, embodiment). From deployment perspective, a better integration with other IT tools should be realized. Couplings between KBE applications, Knowledge Bases and Simulation Workflow Management software are of particular importance. The iProd project tries to take KBE to the next level by addressing these aspects.[20] The iProd framework uses KBE technology as a reasoning mechanism to infer new product knowledge and, as a means to automate virtual execution (CAE simulation) and as MDO-enabler. On an IT level, it prototypes KB-KBE couplings (code generation, round-tripping, results storage and automatic workflow generation) and SWFM-KBE integration (on the basis of the software-as-a-service paradigm).
It still applies, though the section has disappeared.

Remarks: Modified: 03/23/2017

03/23/2017 --

Wednesday, March 22, 2017

Does code matter?

Three years ago, I spent a little time with Codecademy (post: Codecademy, again). My profile is still there, from that time.

My purpose was to review progress by looking at the tools that were available. For a month, I went through the lessons and worked the exercises. It was interesting to see the on-line instruction. Naturally, I found a few bugs but overlooked them. At the time, it was free; now, there is a Pro option with more of a focus on results.

Also, at the time, I saw testimonials about people starting careers with this approach. That was interesting. Today, I ran into another (different method) that represents the time. The guy has blogged about his introduction into coding and the success that he has found.
Then, I saw that one of morning show hosts talked to someone about an effort to teach coding to women. There are thousands of jobs open, I understand.

Hence, this little reminder. One problem with so many people just coding is that we're losing sight of issues related to quality (many issues). And, one sees this lack everywhere. Quality would include the user perspective, especially concerns related to safety, stability, and such.

I have already written about little businesses being bitten (Content and more). I just ran across an issue myself the past week: Technology's impact. So, we have issues related to content's management, efficacy of technology's use, and whole lot more.

But, a very important one relates to this theme: Does code matter? Based upon my experience, this glut of jobs is short-sighted. Code does not provide the business intelligence that everyone is after. Now, if code is mainly small perturbations (such as was brought by macro ability in spread sheets), then, that could very well be content related.

However, how many times do we need to re-invent the wheel?

Remarks: Modified: 03/23/2017

03/23/2017 -- Two recent videos (stumbled upon them). 1) Peter Metzger talks about his 31 years with Emacs. He shows a little of the history of computing devices. Run down memory lane. But, nice to see the old thing, Emacs, still having traction. 2) Which then brings up Richard Stallman. Richard started Emacs ball rolling (some have followed his sainthood into the editor wars - Emacs vs VI/VIM).

Also, he was first in looking at truth maintenance. But, in this video, Richard talks about his free software initiative and emphasizes, time and again, that purty systems, like Apple, have created a jail, made it purty, and then convinced people to jail themselves. He does not like what I call the dumbing device. He stresses surveillance. I see it as a tether to nonsense. Hence, I am 1G/2G, even in this day of talk about 5G. In terms of truth maintenance, Richard and his advisor (Sussman) worked on constraint satisfaction. Another aspect deals with defeasible reasoning.

Saturday, February 25, 2017

Big T-issues

All along, I have alluded to big-T issues. See category, T-issues.

Of late, I have started to address these. That is, way before the even of November. Then, fake news came about, mostly due to social media. Gosh, were some of these things foreseen?

Who do you believe? There are lots of things to discuss about how truth engineering fits in the picture. And, time will tell how this will go.

I have been using a blog on Quora (see Psychether) to lay out some thoughts. Today, I picked up a nice graphic from Craig Weinberg. Again, lots to discuss, however truth (and its assessments) is very much related to consciousness. I have been sampling work that is cosmological or physics in basis.

Now, the subject used big T. Consider that we do not have to extend the view that far in order to be effective. 

Remarks: Modified: 02/25/2017

02/25/2017 --

Friday, December 30, 2016

Summary, 2016

Prior years:  201120122013, 2014, 2015.

Remarks: Modified: 12/30/2016

12/30/2016 --

Tuesday, November 8, 2016

New Day, again

Back in 2009, we wrote a post (A New Day). We mentioned that the new President talked about the need to move away from greed and irresponsibility. Have we seen that?

We have two candidates who were 21 and 20 in that seminal year of 1967 (flower child unfoldment). So, we can say that we are experiencing, finally, the fruits from those times.

Lots to look at.

See sister blog: 7'oops7.

Remarks: Modified: 11/08/2016

11/08/2016 --

Sunday, October 30, 2016

Silly Valley

The Atlantic suggests that, at least, one person in Silly Valley has a conscience: The Binge Breaker. Tristan  Harris, actually, discusses people playing humans as if on a line. This makes Zack's little experiments look amateur.

Several places, I have cautioned that Silly Valley is enmeshing us in a very ominous manner. To them, it is just fair game in the unicorn environment. No one of them wants to be (seen as) a loser.

Human dignity? Went out the window, evidently.

Here, I have argued that man-in-the-loop will become (continue to be) of importance in anything dealing with truth and complexity. That approach goes against the grain that has been honed for the past 200 years.

Time for a re-look.

Related themes: Overlay, Entrapment, ...

Remarks: Modified: 10/31/2016

10/31/2016 -- Being on Quora for the past year helped develop the sense of how to address the need for truth engineering. Devices play a major part. Differences in presentation related to devices do so, as well. Lots to look at. ... IEEE weighed in, long ago. This statement is not a conflation, rather we really need to reassess what we think of people and mind.

Monday, October 3, 2016

Truth and nature

In another context, there was discussion about phenomena that is particular to humans. You now, consciousness is one. There are several.

Now, limiting the discussion to a few, we can start to deal with some issues that seem to generate a whole lot of angst. The sides of the arguments split with a wide gap.

Essentially, we are going to argue that nature does not deal with truth. Nature is, just like we are. What has happened is that humans have truth engineered over the eons that we have been around.

And, since the computational progress has accelerated, we find ourselves in a bind (actually, several binds). Computers deal with truth; it's at its core. So, we now have a cloud that is becoming increasingly muddy. Why? No one is really looking at this beyond local views.

But, is there one of greater extent? Ah. Yes. Does that necessitate that we bring in the metaphysical aspects of so much controversy? Well. Not really.

The approach rests upon using psychether as the operational basis. How can this be? That, pray tell, is the main thing to work on and use to advance the importance of truth engineering.

Remarks: Modified: 10/31/2016

10/31/2016 -- Time to weigh in, more deeply