Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>
Clone
HTTPS:
git clone https://vervis.peers.community/repos/yEzqv
SSH:
git clone USERNAME@vervis.peers.community:yEzqv
Branches
Tags
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:
- It’s possible to import a sub-namespace, expressed as a PLref, not just a flat prefix-Uid pair
- It’s possible to have any number of “default” namespaces, i.e. a set of “imported” namespaces whose content doesn’t need a prefix prepended
- It’s possible to import namespaces under alternative names
- It’s possible to import specific members of namespaces, rather than all of them
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 prefixppl
. It contains a labelPerson
which refers to the Person class, the class of all people. Then a PLrefppl: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 labelis_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:
- Declaring a VS namespace in the header
- Declaring a KH namespace in the header
- Declaring a default VS namespace
Which names are brought into scope:
- Declared VS namespace: the namespace prefix
- Imported KH namespace: all labels it contains, and the namespace prefix
- Qualified KH namespace: the namespace’s locally specified label
- Default VS namespace: all labels it contains, and the namespace prefix
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 memberthing
can be accessed asmyns:thing
, and the Uid ofmyns
itself can be accessed in two ways: either simply asmyns
, or prefixed with a at-sign, i.e. as@myns
.When a KH namespace
Myns
is imported, its memberThing
can be accessed directly asThing
, andMyns
itself can be referred to as*Myns
.When a qualified KH namespace is declared, with declared label
Label
, its memberThing
may be accessed asLabel.Thing
, and the namespace itself can be referred to asLabel
or as*Label
.When a default VS namespace
myns
is declared, its memberthing
can be accessed asthing
,:thing
ormyns:thing
. The namespace itself can be referred to asmyns
or@myns
.dev
What is in scope by default? Just
True
andFalse
.What can namespace declarations do?
- Declare a name and a Uid, bringing into scope
- Declare a namespace, bringing its content into scope (or specific content)
- 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:
- Name (possibly hierarchical)
- Uid or PLref to resolve externally
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:
- Flat and hierarchical namespaces, including ability to define a flat label
- Content of namespaces, either entire content or specific members
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?
- Bring namespace with hierarchical reference, and use it as a name
- Same, but with a flat label for easier access
- Bringing specific contents of a namespace into the Empty scope
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.