Deno Developer

Deno Developer

1605095460

A simple immutable distributed knowledge base for tribles

tribles-deno

This is the deno implementation of the tribles ecosystem.

It is still in early development.

Status

So far the following components have been implemented.

  • PART js implementation.
  • TribleDB js immutable trible database.
  • TribleKB js immutable trible knowledge-base.
  • Core types:
    • UUID
    • Shortstring
    • Longstring
    • Spacetimestamp

Currently to be done and missing is:

  • PART rust implementation.
  • TribleDB rust implementation.
  • TribleMQ js middleware communications libary.
  • JS Ontology tools to dynamically load TribleKB contexts and documentation from Trible based ontologies.
  • Core number types.
  • More types…
  • Even more types…
  • An ontology describing everything.

Elevator Pitch

Many modern applications from chatbots and robots to project management applications and wikis have the need for some form of flexible knowledge represenation, that goes beyond the capabilities of traditional RDBMS. However existing technologies like the Semantic Web with its RDF, SPARQL, jsonLD, and OWL based standards are too complex, and transitively rely on further complexity from other web standards. This results in few implementations, which are often incomplete and infrequently maintained. However, the theoretical foundations and ideas of these standards are often good and sound, what we need is “Semantic Web, the good parts”. What we need is the linked list of knowledge representation. [1]

Example: Todo List

import {
  assertArrayIncludes,
  assertEquals,
} from "https://deno.land/std@0.75.0/testing/asserts.ts";
import { v4 } from "https://deno.land/std@0.76.0/uuid/mod.ts";

import { id, TribleKB, types } from "../mod.js";

Deno.test("Integration", () => {
  const observation_attr = v4.generate();
  const state_open = v4.generate();
  const state_done = v4.generate();

  // Define a context, mapping between js data and tribles.
  const todo_ctx = {
    [id]: { ...types.id, id: v4.generate() },
    observationOf: {
      isLink: true,
      id: observation_attr,
    },
    observedAs: {
      isInverseLink: true,
      id: observation_attr,
    },
    task: {
      ...types.shortstring,
      id: v4.generate(),
    },
    state: {
      isLink: true,
      id: v4.generate(),
    },
    stamp: {
      ...types.spacetimestamp,
      id: v4.generate(),
    },
    createdBy: {
      isLink: true,
      id: v4.generate(),
    },
    name: {
      ...types.shortstring,
      id: v4.generate(),
    },
  };
  const kb = new TribleKB();

  // Add some data.
  const observation_id = v4.generate();
  let todos = new TribleKB().with(todo_ctx, ([t]) => [
    {
      task: "Get almondmilk!",
      observedAs: [
        {
          [id]: observation_id,
          state: state_open,
          stamp: { t: 0n, x: 0n, y: 0n, z: 0n },
        },
      ],
      createdBy: { name: "jp" },
    },
  ]);

  // Query some data.
  const [first_result] = todos.find(
    todo_ctx,
    ({ observation, stamp, task }) => [
      {
        [id]: observation.walk(), //Walk will create a proxy object which allows us to navigate the graph as a JS tree.
        stamp: stamp.at(0),
        observationOf: { task, createdBy: { name: "jp" } },
      },
    ],
  );

  assertEquals(first_result.observation.state[id], state_open); //Notice the walk() in action.
  assertEquals(first_result.task, "Get almondmilk!");
  assertEquals(first_result.stamp, { t: 0n, x: 0n, y: 0n, z: 0n });
});

Background and Fundamentals

Triples and Tribles (and Blobs)

The fundamental building block of the tribles ecosystem is the trible. Tribles, are binary triples, encoded as 64byte long immutable values, that consists of three parts, an entity, an attribute, a value, or to use their semantic web names, a subject, a predicate, and an object. Entity and attribute are both 16byte wide, and hold a random or pseudorandom identifier like a UUID. [2] The value is 32byte wide and can hold arbitrary data. Any data longer than 32byte is hashed with a function of the users choice, e.g. blake2s, and stored as a blob. This separation of long and short data has a few advantages:

  • It makes storing large binary data trivial.
  • It allows for the system to eagerly share knowledge about this data, while being lazy about performing the actual transfer.
  • It allows for interesting optimisations when indexing the now fixed size tribles.

The lengths of E,A, and V were chosen so that the frequency of collisions in IDs or Hashes is far less likely than the system producing bad data from CPU errors. [3]

TribleDB and TribleKB

Tribles are stored in TribleDB, a persistent (not in the durable, but immutable sense), append only, in memory database. It provides conjunctive queries and constraint solving over tribles, but is completely limited to binary data.

Datalog like conjunctive queries are great if your language is build around hypergraphs, e.g. Prolog. Alas most languages we use today are build around trees, and therefore profit from languages that return trees or tree unfoldings of graphs. A good example for this is GraphQL, although it is more of a RPC tool than a query language. JSON-LD is another candidate, and while we found the static conversions of JSON data to be cumbersome, we’ve adapted many concepts from it.

TribleDB is therefore wrapped by TribleKB, which performs conversions between JS Objects and trible data, provides tree interfaces for data insertion, and tree based query capabilites, as well as tree-based graph walking capabilites, all operating over familiar plain old javascript objects (and proxies cough).

Contexts, Types and Ontologies

The thing that JSON-LD realy got right, is their decoupling of the underlying data representation (in their case RDF) and the user facing representation. If different systems are to exchange information, or if a single system is upgraded, there needs to be some form of neutral representation, in our case bytes. By giving the user the ability to provide contexts in which the underlying tribles can be interpreted as needed, we can:

  • Provide easy upgrade paths for legacy systems. Old parts can read old representations, new parts can read new representations, or a mix thereof.
  • Decouple programming language types from value types. E.g. a timestamp can be read as different date types in the same query.
  • Allow the user to use approprate, self explanatory, names. One programmers legacy_date is another programmers sanity_check_date.
  • Allow users to fix past mistakes or missunderstandings. Whenever a name in OWL is used it’s used. Trible don’t care about names, only about IDs.

Typing has drawn heavy inspiration from RDFS, in that the type of a value (the meaning of the layout of bytes, not the represenation in a programming language) is only depending on the attribute itself. With one type per attribute id. This has the advantage of giving statically typed programming languages like Rust the ability to properly type queries with the help of statically generated contexts.

The above information is itself stored as tribles in the form of an ontology. You can think of it as a schema in an RDBMS, with the addition of it also containing documentation and meta information.

  • [1] Lispers will probably argue that the linked list is the linked list of knowledge representation.
  • [2] Someone with an RDF background might recognize these as skolemized blank-nodes.
  • [3] Unless maybe you’re using a system with redundant CPUs, e.g. Rocket Control. In which case: “Why does your rocket need a knowledge base!!??”

Download Details:

Author: triblesspace

Demo: http://tribles.space/

Source Code: https://github.com/triblesspace/tribles-deno

#deno #node #nodejs #javascript

What is GEEK

Buddha Community

A simple immutable distributed knowledge base for tribles
Deno Developer

Deno Developer

1605095460

A simple immutable distributed knowledge base for tribles

tribles-deno

This is the deno implementation of the tribles ecosystem.

It is still in early development.

Status

So far the following components have been implemented.

  • PART js implementation.
  • TribleDB js immutable trible database.
  • TribleKB js immutable trible knowledge-base.
  • Core types:
    • UUID
    • Shortstring
    • Longstring
    • Spacetimestamp

Currently to be done and missing is:

  • PART rust implementation.
  • TribleDB rust implementation.
  • TribleMQ js middleware communications libary.
  • JS Ontology tools to dynamically load TribleKB contexts and documentation from Trible based ontologies.
  • Core number types.
  • More types…
  • Even more types…
  • An ontology describing everything.

Elevator Pitch

Many modern applications from chatbots and robots to project management applications and wikis have the need for some form of flexible knowledge represenation, that goes beyond the capabilities of traditional RDBMS. However existing technologies like the Semantic Web with its RDF, SPARQL, jsonLD, and OWL based standards are too complex, and transitively rely on further complexity from other web standards. This results in few implementations, which are often incomplete and infrequently maintained. However, the theoretical foundations and ideas of these standards are often good and sound, what we need is “Semantic Web, the good parts”. What we need is the linked list of knowledge representation. [1]

Example: Todo List

import {
  assertArrayIncludes,
  assertEquals,
} from "https://deno.land/std@0.75.0/testing/asserts.ts";
import { v4 } from "https://deno.land/std@0.76.0/uuid/mod.ts";

import { id, TribleKB, types } from "../mod.js";

Deno.test("Integration", () => {
  const observation_attr = v4.generate();
  const state_open = v4.generate();
  const state_done = v4.generate();

  // Define a context, mapping between js data and tribles.
  const todo_ctx = {
    [id]: { ...types.id, id: v4.generate() },
    observationOf: {
      isLink: true,
      id: observation_attr,
    },
    observedAs: {
      isInverseLink: true,
      id: observation_attr,
    },
    task: {
      ...types.shortstring,
      id: v4.generate(),
    },
    state: {
      isLink: true,
      id: v4.generate(),
    },
    stamp: {
      ...types.spacetimestamp,
      id: v4.generate(),
    },
    createdBy: {
      isLink: true,
      id: v4.generate(),
    },
    name: {
      ...types.shortstring,
      id: v4.generate(),
    },
  };
  const kb = new TribleKB();

  // Add some data.
  const observation_id = v4.generate();
  let todos = new TribleKB().with(todo_ctx, ([t]) => [
    {
      task: "Get almondmilk!",
      observedAs: [
        {
          [id]: observation_id,
          state: state_open,
          stamp: { t: 0n, x: 0n, y: 0n, z: 0n },
        },
      ],
      createdBy: { name: "jp" },
    },
  ]);

  // Query some data.
  const [first_result] = todos.find(
    todo_ctx,
    ({ observation, stamp, task }) => [
      {
        [id]: observation.walk(), //Walk will create a proxy object which allows us to navigate the graph as a JS tree.
        stamp: stamp.at(0),
        observationOf: { task, createdBy: { name: "jp" } },
      },
    ],
  );

  assertEquals(first_result.observation.state[id], state_open); //Notice the walk() in action.
  assertEquals(first_result.task, "Get almondmilk!");
  assertEquals(first_result.stamp, { t: 0n, x: 0n, y: 0n, z: 0n });
});

Background and Fundamentals

Triples and Tribles (and Blobs)

The fundamental building block of the tribles ecosystem is the trible. Tribles, are binary triples, encoded as 64byte long immutable values, that consists of three parts, an entity, an attribute, a value, or to use their semantic web names, a subject, a predicate, and an object. Entity and attribute are both 16byte wide, and hold a random or pseudorandom identifier like a UUID. [2] The value is 32byte wide and can hold arbitrary data. Any data longer than 32byte is hashed with a function of the users choice, e.g. blake2s, and stored as a blob. This separation of long and short data has a few advantages:

  • It makes storing large binary data trivial.
  • It allows for the system to eagerly share knowledge about this data, while being lazy about performing the actual transfer.
  • It allows for interesting optimisations when indexing the now fixed size tribles.

The lengths of E,A, and V were chosen so that the frequency of collisions in IDs or Hashes is far less likely than the system producing bad data from CPU errors. [3]

TribleDB and TribleKB

Tribles are stored in TribleDB, a persistent (not in the durable, but immutable sense), append only, in memory database. It provides conjunctive queries and constraint solving over tribles, but is completely limited to binary data.

Datalog like conjunctive queries are great if your language is build around hypergraphs, e.g. Prolog. Alas most languages we use today are build around trees, and therefore profit from languages that return trees or tree unfoldings of graphs. A good example for this is GraphQL, although it is more of a RPC tool than a query language. JSON-LD is another candidate, and while we found the static conversions of JSON data to be cumbersome, we’ve adapted many concepts from it.

TribleDB is therefore wrapped by TribleKB, which performs conversions between JS Objects and trible data, provides tree interfaces for data insertion, and tree based query capabilites, as well as tree-based graph walking capabilites, all operating over familiar plain old javascript objects (and proxies cough).

Contexts, Types and Ontologies

The thing that JSON-LD realy got right, is their decoupling of the underlying data representation (in their case RDF) and the user facing representation. If different systems are to exchange information, or if a single system is upgraded, there needs to be some form of neutral representation, in our case bytes. By giving the user the ability to provide contexts in which the underlying tribles can be interpreted as needed, we can:

  • Provide easy upgrade paths for legacy systems. Old parts can read old representations, new parts can read new representations, or a mix thereof.
  • Decouple programming language types from value types. E.g. a timestamp can be read as different date types in the same query.
  • Allow the user to use approprate, self explanatory, names. One programmers legacy_date is another programmers sanity_check_date.
  • Allow users to fix past mistakes or missunderstandings. Whenever a name in OWL is used it’s used. Trible don’t care about names, only about IDs.

Typing has drawn heavy inspiration from RDFS, in that the type of a value (the meaning of the layout of bytes, not the represenation in a programming language) is only depending on the attribute itself. With one type per attribute id. This has the advantage of giving statically typed programming languages like Rust the ability to properly type queries with the help of statically generated contexts.

The above information is itself stored as tribles in the form of an ontology. You can think of it as a schema in an RDBMS, with the addition of it also containing documentation and meta information.

  • [1] Lispers will probably argue that the linked list is the linked list of knowledge representation.
  • [2] Someone with an RDF background might recognize these as skolemized blank-nodes.
  • [3] Unless maybe you’re using a system with redundant CPUs, e.g. Rocket Control. In which case: “Why does your rocket need a knowledge base!!??”

Download Details:

Author: triblesspace

Demo: http://tribles.space/

Source Code: https://github.com/triblesspace/tribles-deno

#deno #node #nodejs #javascript

What is Base Protocol (BASE) | What is BASE token

Base Protocol (BASE) is a token whose price is pegged to the total market cap of all cryptocurrencies at a ratio of 1:1 trillion. BASE allows traders to speculate on the entire crypto industry with one token. The Base Protocol is built on the Ethereum blockchain, integrates a (Chainlink) oracle, and is launching on ((Uniswap)

As cryptocurrency enthusiasts, we’re sometimes divided on which digital assets to buy — bullish on certain projects and bearish on others.

But we all agree on one thing, which is that the overall cryptocurrency industry will achieve long-term growth and future adoption.

The Base Protocol makes it possible to invest with this consensus. BASE allows traders to speculate on the entire industry with one token.

Image for post

The Base Protocol is the world’s first and only tokenized cryptocurrency market tracker. By holding BASE tokens, users can get exposure to the performance of the entire cryptocurrency market. Unlike the index trackers currently operating in the traditional markets, there is no entry or exit fee or brokerage charges.

Index funds have consistently outperformed actively managed mutual funds. Until the launch of BASE, there was no real cryptocurrency market tracker that tracked the performance of the entire digital asset market. BASE will be useful for institutional investors and traders to diversify and hedge their crypto portfolios. BASE will also help new and existing retail investors to take out the guesswork and get exposed to the growth of all current and future digital assets entering the market.

The BASE token’s underlying protocol creates several additional use cases in DeFi, trading, venture capital, hedge funds and many other business sectors.

The Base Protocol mission is simple — to make it easy for everyone to benefit from the performance of the entire cryptocurrency market in a secure, decentralized and future-proof way.

Why BASE?

It’s no doubt that a crypto industry ETF would be a valuable product for investors. But it is very challenging to create such a product through traditional means, as it would be almost impossible to manage portfolio ownership of 5,000+ assets. How would the portfolio manager weigh ownership of each asset as market cap dominance changes? How would they account for newly entering/exiting assets? Who would take on all the associated transaction and custodial fees? There are also various legal limitations that restrict the formation of such an instrument in many countries — and even if it could be formed, it would be a highly centralized product.

By simply pegging price to the total market capitalization of all cryptocurrencies, the Base Protocol cuts through all of these problems. BASE gives holders the same function as a traditional industry ETF without all of the centralized challenges that make such an ETF impossible.

BASE will offer new value for investors in the cryptocurrency ecosystem through an elegantly simple protocol — so valuable and so simple that you might be asking yourself:

How has this not been done before?

The answer is that it wasn’t possible until recently. This project couldn’t be achieved without a robust decentralized blockchain, proven oracle integrations, and new developments in the DeFi space. We founded the Base Protocol to build on these innovations and create BASE; one tokenized asset that represents speculation on all cryptocurrencies.

Vision

We’ve seen that there are many individuals who want to invest in cryptocurrencies, but don’t necessarily understand how they work. While the overview for each different crypto asset can be difficult to understand for a new user, the pitch for BASE is simple: it’s the way to invest in all of those crypto assets simultaneously. In this way, the Base Protocol can become an instrumental force in driving new adoption in the blockchain space.

We’ve also noticed that institutional investors have been introducing cryptocurrency investments to their portfolios. These institutions typically invest at a high level with great diversification covering multiple industries. Their cryptocurrency holdings are usually composed of just Bitcoin, or some handful mix of “blue chip” digital assets. By holding BASE, these institutions will gain exposure to the entire cryptocurrency industry — an objectively more diversified alternative.

In the same way that Bitcoin is the household name of cryptocurrencies, the Base Protocol aims to become the household name for general cryptocurrency investing. BASE’s vision is to become the primary channel of investment for new/existing cryptocurrency traders and institutional investors.

Would you like to earn token right now! ☞ CLICK HERE

Looking for more information…

☞ Website
☞ Explorer
☞ Source Code
☞ Social Channel
Message Board
☞ Coinmarketcap

Create an Account and Trade NOW

Bittrex
Poloniex
Binance

Thank for visiting and reading this article! I’m highly appreciate your actions! Please share if you liked it!

#blockchain #bitcoin #crypto #base protocol #base

August  Larson

August Larson

1624298520

Sampling Distributions with Python

College Statistics with Python

Introduction

In a series of weekly articles, I will be covering some important topics of statistics with a twist.

The goal is to use Python to help us get intuition on complex concepts, empirically test theoretical proofs, or build algorithms from scratch. In this series, you will find articles covering topics such as random variables, sampling distributions, confidence intervals, significance tests, and more.

At the end of each article, you can find exercises to test your knowledge. The solutions will be shared in the article of the following week.

Articles published so far:

As usual, the code is available on my GitHub.

#statistics #distribution #python #machine-learning #sampling distributions with python #sampling distributions

Gps Location Based App Development

In the search for trends, more and more geo-dependent mobile applications have been appearing on the market. Some of them cannot work without locating the user, while others are taking advantage of the geolocation feature to make their services more accessible. Navigators, guides, social networks with geotagged photos, fitness applications with route tracking belong to so-called Location-Based Services.

DataIT Solutions development expertise helps you get the most accurate GPS location-based solutions with highly-reliable GPS tracking modules including driving estimations, dynamic condition filtering, yielding the best consumer experience.

Location-Based App Development Helps In:

  • Identifying the position of a person or an object
  • Measurement of distance between two objects
  • Building optimum routes from one point to another

A location-based app needs an interactive UI along with strong backend server functionalities such as:

  • GPS coordinates of the location
  • Receiving the current location of the user
  • Serving the nearby locations
  • Directions for driving or walking
  • Map integration

We build innovative mobile apps that are instantly deployable for navigation & search, weather, field services, asset-tracking, proximity-based marketing, geofencing services, and more. Our beacon-compatible mobile applications deliver engaging UX for indoor-outdoor locations while enhancing existing business processes, productivity, and revenues.

Location-based apps are a great mobile development segment. It is still possible to come up with an innovative idea and become a giant in this enterprise.

Hire a Dedicated Development Team to develop your location-based apps and set your business apart from your competition.

#gps location based app development #app development #location based app development #gps location-based solutions #location-based app development #mobile-apps

Joseph  Murray

Joseph Murray

1624063200

Creating an Immutable Class in Java

In this article, we’ll define the typical steps for creating an immutable class in Java and then implement it.

Steps to create Immutable class in java

  1. Make your class final, so that no other classes can extend it.
  2. Make all fields private so that direct access is not allowed.
  3. Don’t provide “setter” methods — methods that modify fields or objects referred to by fields.
  4. Special attention when having mutable instance variables
  5. Inside the constructor, make sure to use a clone copy of the passed argument and never set your mutable field to the real instance passed through the constructor.
  6. Make sure to always return a clone copy of the field and never return the real object instance.

#java #class #objects #immutable #creating an immutable class in java #immutable class in java