123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160 |
- **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
|