Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

[[ 🗃 ^yEzqv rel4tion-wiki ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

Tags

master :: projects / idan / tickets /

6.mdwn

[[!template id=ticket class=task]] [[!tag /projects/idan/decisions]]

[[!meta title=“Define scope model”]]

[[!toc levels=3]]

Issue

The current way to bring namespaces for use with PLrefs is somewhat weak. It’s more or less the same as what RDF/XML uses, but much less flexible that what many programming languages do, including ones nearly-flat namespace hierarchies (like C++) and ones with deep organized hierarchies (like Haskell).

Which scheme should Idan use? Which features should it support? What are the strengths and weaknesses of them, and how are they related to the various usage patterns Idan should support?

PLref Notes

This is text I wrote in the PLref section, in which I explained the freshly made VS/KH concept.

Namespace Systems

There are two namespace systems in Idan. The share the same concept, but the intended use is slightly different. Perhaps in the future, experience and feedback will tell which one is better. Until then, both systems are available and can be mixed freely for flexible prototyping and experimenting.

One system is called the Knowledge Hierarchy (or KH) and other is called the Vocabulary Space (or VS). There isn’t really a deep conceptual difference; the names simply provide a way to specify which system is being used or discussed. Both systems support exactly the same feature: a hierarchy of prefixes and labels. But the way these hierarchies and used in Idan documents varies slightly. The KH is meant to be a deep hierarchy organized by domains of knowledge, in some widely agreed scheme. The VS is generally shallow, usually just 1 depth level, sometimes 2, and is generally organized in topic-specific ontologies.

The KH comes from programming languages like Python, Haskell and Java, which have module hierarchies, and from book libraries, which are highly organized into knowledge domains. The VS comes from programming languages like C++, which have a generally shallow namespace hierarchy, and from the namespace prefixes as used in XML and RDF.

The usage of VS in Idan is simple. There is a set of namespaces declared in the header part of the document, prefix and Uid for each namespace. The prefixes can then be used in PLrefs, and will be resolved into their Uids when resolving PLrefs. Processing software can also handle other prefixes, not specified in the document, by looking for them in other documents or in a datastore. It is also possible to declare a default prefix in the header, which may be omitted from PLrefs.

For KH, there is more flexibility in importing names for use in the document:

Syntax

PLrefs can be used as subjects, predicates and objects - not identifiers.

VS PLref parts are separated by colons (:). For example, suppose there is a namespace containing definitions related to people, and we assign it a prefix ppl. It contains a label Person which refers to the Person class, the class of all people. Then a PLref ppl:Person can be used to refer to that class:

<%> smaoin:is_a ppl:Person

In this example there is also a namespace smaoin, and a property with label is_a, which is a member of it. VS PLrefs with more parts are possible too, e.g. animals:mammals:Human.

When the default prefix is used in a VS PLref, it may be omitted, in which case the PLref begins with a colon. For example :mammals:Human.

KH PLrefs are separated by periods (.). For example, Nature.Life.tree. The first name can either be a prefix, or be a label of a namespace which belongs to a namespace imported in the header. Unlike with the leading : in VS PLrefs, there is no leading character needed here.

Note that this syntax doesn’t cover the case of referring to a declared VS namespace or to a declared or imported KH namespace. These are covered in the next section.

NSref Notes

These are notes I wrote for NSrefs while creating the VS/KH idea in my head:

A namespace reference, or NSref, is a reference which specifies a label in the file’s scope of names. The definitions below aren’t accurate because they don’t take the human interface system fully into account, but the chapter about it provides the full definitions.

What can bring names into scope:

Which names are brought into scope:

As an experiment for feedback and studying, Idan provides several forms for these references. There are prefixed forms, and “clean” forms which use the scope directly, and may cause ambiguity if conflicting names are imported.

When a VS namespace myns is declared in the header, its member thing can be accessed as myns:thing, and the Uid of myns itself can be accessed in two ways: either simply as myns, or prefixed with a at-sign, i.e. as @myns.

When a KH namespace Myns is imported, its member Thing can be accessed directly as Thing, and Myns itself can be referred to as *Myns.

When a qualified KH namespace is declared, with declared label Label, its member Thing may be accessed as Label.Thing, and the namespace itself can be referred to as Label or as *Label.

When a default VS namespace myns is declared, its member thing can be accessed as thing, :thing or myns:thing. The namespace itself can be referred to as myns or @myns.

dev

What is in scope by default? Just True and False.

What can namespace declarations do?

  1. Declare a name and a Uid, bringing into scope
  2. Declare a namespace, bringing its content into scope (or specific content)
  3. Specify default namespace

1

@namespace "myns" <0000-0000-0000-0000>

import qualified Data.List

2

import Data.Char (isMark)

3

@default "myns"

Concepts

What is a scope? What is a scope model?

A scope is a mapping between names and values. In the case of Smaoin and Idan, it’s a mapping between prefixes or labels to the Uids they represent in a human-friendly way. The entries in a document’s header may affect scopes, by adding new items to the mapping.

So far there have been 2 scopes. One is the scope of names available as-is in the document, without prefixes or special syntax forms. For example, in the PLref ppl:Person, the prefix ppl doesn’t have any identifying character before it, unlike all the positional references (#^, $,, etc.). The second scope is the colon scope. It’s the scope available by beginning a PLref with a colon, e.g. :Person. This is possible if ppl is declared as the default namespace in the header.

These two scopes are called Empty and Colon, respectively.

By default, the Empty scope contains only two names: True and False. The Colon scope is empty unless a default namespace is declared.

A scope model is a system which provides a set of scope giving access to values through names, and a set of tools for controlling the contents of these scopes. For example, VS and KH are scope models.

Discussion

What are the tools a scope model should provide? What do they look like? Perhaps in general, it should provide a insertion operation. It inserts a set of names into a scope. Parameters of an insertion:

If the name is empty, then all the namespace members are inserted directly into the global scope.

It seems that KH covers these properties. Is there anything special about VS then? Is VS just a subset of what KH provides? Let’s assume it’s a subset and try to prove. The only thing VS can insert into the Empty namespace is flat namespaces, specified by prefix and Uid. KH is more powerful. It can insert:

VS can insert a single namespace’s content into the Colon scope, but the only advantage of this over just using the Empty scope is that it protects from name collisions between namespace contents and the namespace prefixes declared in the header (and True and False).

Indeed KH is flexible, but the flexibility has a price. When writing in the Empty scope, it’s not clear from the text which namespace is being used, because a given name can come from any of the imported namespaces. This is dangerous, because unlike in Haskell, there is no type system here to save the user. A mistake will cause false information to be inserted into the datastore.

What about the default namespace feature of VS? Is it a good idea? Perhaps Smaoin should always be the default? Is smaoin not too long for a commonly used prefix? Maybe replace with the shorter sma? Or even import smaoin directly into the Empty scope, as a feature of Idan?

What are the good things we can take from KH?

The problem of deep hierarchies is that they make it difficult to write qualified names. Perhaps a good compromise is to organize in a deep hierarchy by topic, but also have good short names for flat use, even if informal.

Syntax suggestions/examples:

use <0000-0000-0000-0000> as x
use <0000-0000-0000-0000> as x:y
use x:y as z
default z
default x:y

Should I start using informative names, or keep the funny abbreviations? I think I’ll be able to answer this better after trying to construct a hierarchy with the help of the many existing examples.

Also, should bringing specific contents into the Empty scope be allowed? If yes, can they be brought from several different namespaces? In which situations is it useful and worth having?

Decisions

Default namespace/s: Just one, to be accessed as e.g. :thing.

Separator character: Colon (:).

Naming scheme: None yet.

Hierarchy structure: None yet.

Smaoin default/regular/in Empty scope/sma: None yet.

Bringing specific members: No, only namespace prefixes can be declared.

[See repo JSON]