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 :: people / fr33domlover /

old-reorganization.mdwn

Reorganization of the Research Wiki

I want to move this wiki into a git repository. It requires the following steps:

Wiki or Not Wiki

Here is the definition from Wikipedia:

A wiki (i/ˈwɪki/ wik-ee) is usually a web application which allows people to add, modify, or delete content in collaboration with others. Text is usually written using a simplified markup language or a rich-text editor. While a wiki is a type of content management system, it differs from a blog or most other such systems in that the content is created without any defined owner or leader, and wikis have little implicit structure, allowing structure to emerge according to the needs of the users.

In the ideal scenario, my wiki is managed using a Razom interface, i.e. the organization of the content is similar to a Razom based file system. The difference is that it’s a platform for collaborative work, i.e. comments and replies and editing by many people are expected. It’s not exactly a wiki, because it does have the structure coming from semantic tagging, but it’s close enough to be called a wiki. In the real scenario, it’s just a git repository with plain text files, which makes it a wiki without a web interface. I guess I can call it a wiki.

Before I decide: What other names could it have? “Collaboration platform”? Maybe. Let’s just call it a wiki.

Now, I also need to choose a name for the repository. It will be managed by gitolite and I will work with a local copy. Is just “wiki” good enough? Hmmm… what if I add another wiki later? It should be clear what this wiki is used for. IDEA: I’ll call it ‘rdd-wiki’, where ‘rdd’ is short for Research, Design and Development.

Structure

The wiki should be organized according to the components of Partager. The file components contains a list. However, that list was made because I wanted to assign names to the various components, and it doesn’t have the best structure. Let’s think about it here.

Overall, there’s the project as a whole. Partager. Everything related to the semantic system and uses developed by the same team (currently just me) belong to Partager. Inside it there are two kinds of components:

The criterion to determine to which category a component belongs is simple: If it can be created by anyone else outside of Partager and plugged in, it’s an application. Otherwise, i.e. if it has to be integrated with the system, it belongs to the core. In the future there may be more categories, but right now there are just these two.

The system core is a single super-component, called the “semantic data sharing system”. I recently gave it the name Razom. All the other components don’t belong to a single group, so they can be placed on the same folder hierarchy level as Razom is. However, since there are many components, they’ll be grouped into their own categories and sub-projects.

Using the components file and the components I actually started making, let’s build an initial component tree:

Partager: Semantic computing model (o1) (parallel of semantic web) + Razom: Semantic data management and sharing system (o2) (parallel of nepomuk) | + Smaoin: Expression model (m1) (parallel of RDF semantics) | + (no name) “Higher ontology” for data modeling - classes, properties, groups and so on (parallel of RDFS) | + (no name) Ontology for queries (parallel of SPARQL semantics) | + Idan: General purpose high-level semantic data language (m3) (parallel of Turtle) | | + libIdan | | + Skrive: Concrete syntax of the language, probably YAML based (m2) (parallel of Turtle syntax BNF grammar) | | | + libSkrive | + (no name) Low-level data language which uses plain tuples (parallel of N-Triples) | | + Kort: ASCII syntax for this language (m7) | | | + libKort | | + Alpa: Unicode syntax for this language (m8) | | | + libAlpa | + (no name) Query language | | + syntax for the language | + programming modules | | + SGP: General purpose C++ utilities (a1) | | + Dilosi: Statement interface (a2) (parallel of Soprano) | | + Alder: Object-semantic mapper for programming with semantic objects (a3) + Kiwi: Ontologies for describing information (issues, documents, music, movies, permissions, people and so on) + domain-specific languages for data definition | + language for tasks

This tree is different from the current folder structure, because it puts the design and the implementation of things together: e.g. libKort and Kort planning are together, instead of having a separate planning folder and a separate software folder.

There are more components in my wiki, not included in the tree:

Updated tree:

Partager: Semantic computing model (o1) (parallel of semantic web) + Razom: Semantic data management and sharing system (o2) (parallel of nepomuk) | + Smaoin: Expression model (m1) (parallel of RDF semantics) | + (no name) “Higher ontology” for data modeling - classes, properties, groups and so on (parallel of RDFS) | + (no name) Ontology for queries (parallel of SPARQL semantics) | + Idan: General purpose high-level semantic data language (m3) (parallel of Turtle) | | + libIdan | | + Skrive: Concrete syntax of the language, probably YAML based (m2) (parallel of Turtle syntax BNF grammar) | | | + libSkrive | + (no name) Low-level data language which uses plain tuples (parallel of N-Triples) | | + Kort: ASCII syntax for this language (m7) | | | + libKort | | + Alpa: Unicode syntax for this language (m8) | | | + libAlpa | + (no name) Query language | | + syntax for the language | + programming modules | | + SGP: General purpose C++ utilities (a1) | | + Dilosi: Statement interface (a2) (parallel of Soprano) | | + Alder: Object-semantic mapper for programming with semantic objects (a3) + Kiwi: Ontologies for describing information (issues, documents, music, movies, permissions, people and so on) + domain-specific languages for data definition | + language for tasks + applications + hot (for each hot topic, specify who’s working on it) + inbox (anyone can put things here if not sure where they belong or have no time to find right location, but the same person is then responsible for moving them later and the inbox must not get filled with time!) + concept glossary + components & names + public face + issues (includes todo and goals) + utilities | + C++ skeleton | + gedit snippets | + guides | + skapa

Good, now start carefully moving things into the rdd-wiki, make sure not to move personal things and large files…

[See repo JSON]