Rel4tion-Wiki/projects/naya.mdwn

**page under contruction**

links:

- [[data]]
- [[decisions]]

<div class="infobox">
<h2>Links</h2>

<ul>
<li> [[News]]
<li> [[Releases]]
<li> [[Forum]]
<li> [[Tickets]]
</ul>
</div>

[[!toc]]

# Introduction

**Naya** is a query model designed to be used with the [[Smaoin]] semantic
information model.

# Documentation

+ [[Tutorial]] - friendly guide for learning Naya
+ [[Manual]] - reference material with explanations and examples

# Software

None. Naya is a just a model, therefore any software here will probably be just
helper utilities.

# Data

These are the information documents which provide the actual precise definition
of Naya. See [[here|data]].

# Community

For now, see the [[/contact]] page.

# Copying

All the data files and specifications for Naya are free culture works. All the
related software is free software.

# Bugs, Ideas, Tasks and Decisions

See these:

- [[tickets]]
- [[decisions]]

-----
-----
-----

[[!template id=todo text="""
Move the things below into reorganized subpages
"""]]

Background
==========

When dealing with reasonably small amounts of data, it is possible to load
all the data from persistent memory into the main memory and process it while
it's there. But when the size of the data grows, it must be loaded in chunks,
otherwise it will cause overflow.

When getting the data from a remote location, the problem is bigger: Even if
the data isn't too big to handle locally, it may take long time to receive
from the remote location.

Also, when processing data chunks locally, the processing may take very long
time for certain operations. For example searching may require going through
the whole data block, just to find a tiny piece of information.

These problems cause the naive approach to reading from a database fail when
scaled: If we read large chunks and search inside them, we:

1. Send a lot of data over the network
2. Load a lot of data to RAM or do a lot of disk I/O for temporary storage
3. Run long computation-intensive operations to extract the information we want

This is where __queries__ come to help us.

Queries allow the same entity which holds the data to also handle storage
mechanisms for efficient searching and matching, which means these operations
become much faster than what we would do on the client side. Queries allow
the server side to filter just the information we need, and avoid sending
unnecessary large chunks over the network. Queries allow the server side to
take the responsibility over efficient disk space management, which minimizes
access to the disk and allows the client side to work with the small data
sizes it needs in the same usual way it does file I/O.

As you can see, these are the main advantages and the reasons for the
existence of __databases__ in general. Queries are indeed a fundamental
component of many database models.



Queries under a Semantic Model
==============================

Object models and relational models have one important thing in common: Both of
them do a significant sacrifice on the mathematical models of information, for
the gain of human friendliness of the model, better structure and modularity,
and maybe easier implementation and lower system resource requirements.

As such, the mathematical models behind them are artificial and limited. As
a consequence the same is true for the query languages: They don't serve as
general purpose query expression tools, but only as a way to express commands
to be applied to the structured data storage. Their scope is limited to the
artificially defined scope of the model.

Semantic models are different in this sense. They are based on fundamental
concepts like sets and relations, and can describe any finite set or relation
with the exactly the same tool, avoiding introduction of new fundamental
artificial structures like tables or trees. Instead, semantic models
use general-purpose graphs to represent sets, elements and the relations
between them.

Due to this difference, query languages for semantic models have one extra
responsibility. And unless you're an expert in logic and set theory, this
responsibility is quite heavy. Queries under semantic models __question and__
__examine the theoretical mathematical scope, limits and broadness of question__
__expressions and logic formulas__.

Since query languages for semantic models already exist, I could just pick one
and adapt it to my needs. But then the result wouldn't be better than the tool
I started with. I am personally interested in expanding and discovering new
models, tools and techniques, and find logic and set theory very interesting
as a general model for expression of information. Therefore, I decided to
take queries very seriously, explore this area and design a formal detailed
model for expression of queries, independent of any language or syntax.

I called this new model __Naya__.



Naya
====

Here is the documentation of progress and work on Naya:

+ [[Mathematical basis|math-basis]]
+ [[Existing technology|existing]]
+ [[Early design|early-design]]
+ [[SPARQL specification table-of-contents|sparql-toc]]
+ [[SPARQL examples|sparql-examples]]
+ [[Design]]
+ [[Design2]]
+ [[Examples]] for design
+ [[Design3]] discusses issues
+ [[Design4]] introduces an improved model
+ [[Design5]] explores the resolution process