Application Authoring in RDF

In ~2014, we published an open source authoring technology called glue-ml, as part of glue.ai v1.0 (used to be glue.ai, but...ask me what happened, after class - Apache 2.0 license).

In structural terms, this technique is authoring by graph:  

  • Authors create declarative descriptive graphs, governed by ontology types.
    • In the simplest example, an author can save a .ttl (RDF-turtle) file from a text editor, or from an RDF-aware editor such as Protege or TopBraid.
    • Other authors may instead use spreadsheets, or a customized domain-specific editor.
    • Semantic and logical validity of authored graphs is up to the author and tools.  

  • Applications read the graphs as RDF using the most convenient technology.
    • The app reading approach is independent of the authoring tool used, since only the information content of the RDF model is important.
    • Application code knows the ontology used by authored graph, which provides the logical design contract.
      • App impl may use a code-binding approach, when that feels comfortable.
      • Alternately the app impl may treat the authored RDF as a data-source for query.
      • Semantic validity is application dependent
        • Pretending otherwise is the most common sales con in software, forever!
    • Favorite example:  Switchable, layered profile graphs chosen for a runtime launch
      • Strings passed on command line (or other args) refer to named partial-profile graph files in our given deployment
        • Assume deployment offers some file resource space, such as JVM classpath
        • Layering is implicit in conventions for file names and folders
        • Layering is merged away in the next step
      • Named input model files are read and merged into a single cached in-memory model, which is the profile of the launched application.
        • Profile is just the graph-sum of all the input turtle files that were selected by launcher, e.g. at command line.
        • Ontologies used by the input partial-profile files should generally be the same
          • Easy case:  All partial-profiles owl:import the same version of some MyAppProfile_owl.ttl 
      • Launching app now configures its components using the profile, which is just a single graph of typed individuals.  
        • Actual configuration meaning is specific to application, naturally (else, see THE BIG CON)
        • Usually this single graph contains pointers to other artifacts, which may be graphs or other.
          • App may apply pattern recursively, if we want "turtles all the way down".  
      • AppProfile = example ontology for some component descriptions, released as part of the cogchar layer.
        • The 2016 AppProfile schema as a turtle file.
      • The configuration reading code is in the appdapter + cogchar codebase - TODO: look up exact packages

Popular posts from this blog

Streaming analytics in Scala using ZIO and Apache DataSketches (part 1)

Image
First let's look at a trivial example of streaming analytics using ZIO Streams 2.0.9 (on Scala 2.13). https://scastie.scala-lang.org/6AHfPh02S6m0k7aN6bkacA When run, this Scastie just averages some random numbers (gaussian) in a single input stream.  That code is in the trait AvgFun . But we also see a trait called ParAvgFun with the code for rather painless parallel  implementation, using ZIO chunks, via ZStream's  grouped , zipWithIndex , and groupByKey .  Across these two traits, the clean reusability of ZSinks in different pipelines shows a nice design win for the ZIO Streams API.   The code in  ParAvgFun.parAvgUsingChunks  demonstrates a terse and reasonably efficient design for accumulating results using parallel ZStreams (within a single process).  It is applicable to  simple cases where the stream elements are lightweight and similar, and the underlying operations are uniformly easy (like summing numbers).  When instead there is great variability in the cost of proces
Read more

Overview of AxLam model : Nouns, Types, Morphisms

2023-Feb-03 picking up from tweet thread of 220909  AxLam model: Noun (space), Type (paint), Morphism (arrow) AxLam is for writing models using [concepts, types, and morphisms].  Our concepts may be in the form of some data, or less specifically as things we choose to name or refer to in a model.  Over this concept space, we use types and morphisms to define an adjustable descriptive model that directs and regulates processing of the concept data (or other manifestation).  Alternatively and  more approachably we may write in terms of [nouns,  formal classes, and mappings], and this framing is mostly equivalent for informal purposes. Nouns / Concepts / Terms / Data Nouns (i.e. concepts) describe anything we wish to refer to, and need not be explicit or named.  We think of nouns as the space of things we might try to describe, name or refer to.  "Terms" in a type-theoretic sense are nouns.  Real things in the human world that someone cares about are nouns.  In practice when we
Read more

AxioMagic under Spark on cloud (AWS, Azure, ...)

AxioMagic under Spark on ${ cloud  } AxioMagic relies on functional composition over immutable inputs, thus matching modern evaluation frameworks like Apache Spark, which defines a structured approach to managing data contexts of functional evaluation over data frames.  Spark embodies a refinement of both  ETL and MapReduce methodology.  State machines like Spark require computation and storage resources which may come from any cluster, but today are commonly provided from cloud environments, yielding high volume functional computation at predictable usage-based costs.  We especially value Spark for open scientific dataset analysis, where it is common to work with large data files in interchange formats. Essential features of Spark distributed evaluation Spark assembles batch pipelines to pump datasets of structured records through functional tasks (which may  invoke side-effects, with all necessary stipulations).  This pipeline serves to evaluate a given distributed functional algorit
Read more