NOTE: Federation is disabled on this instance!You can test federation between the following instances:
Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>
In order to help people find information faster, the website of Partager can arrange its content, or at least link to it from the main page, by task. In other words, it allows you to choose what you want to do and directs you from there. Possible actions:
Namespaces are used as groups of names, in order to give the names additional information describing where the names come from or which body defines and maintains them. This way name ambiguities are resolved when a name is used for different things.
Therefore namespaces don’t have any meaning semantically. They just group names defined by some body or as a unified group, in order to keep the names from colliding with names from other groups. A name being in a given namespace doesn’t provide any semantic information about that name.
An ontology describes concepts and relations within a given domain, using a common volabulary. For example, an RDFS ontology may describe elements in the field of computer programming, and it then uses elements of RDFS to describe them. In other words the ontology is “written in RDFS”.
The NRL ontology, part of NEPOMUK, has definitions which complete things missing from RDF/S like nrl:Graph, nrl:Ontology and many other things. I can have similar definitions in Idan (possible by using NRL, even without creating a special parallel for Idan).
**** Equivelence and Versioning
There should be a way in Idan to say that two resources refer to the same thing. And it should be possible to say that one ontology is a subontology of the other, and the same for graphs. Let’s see if NRL provides definitions for that.
NRL seems not to, but OWL does have a class equivalence property. However, equivalence can also be expressed by saying A and B are subclasses of each other.
I don’t see anything about subontologies, but maybe a deeper search would find something. Anyway I could easily define that by myself. It’s good for when there’s a new version or people want to share and merge their works.
Read about Gellish and see if there are good things I can use, same for RDF. For example giving uid to statements, allowing statements to be questions/proposals, not just facts. Use measurement units for values. But try to add them in an extensible way, i.e. try to add them outside the core language to make is small and simple. *****
TODO HERE: Read about how Gellish, RDF, OWL and Tracker treat namespaces and ontologies: What they are, why they exist, how they work, how analogous ontologies are connected/merged. Then decide and explain here how namespaces and ontologies work. Focus on decentralization of ontologies and namespaces, and distribution of ontologies, namespaces and data. Reading in the W3C standards may be a good way to understand how and why things were planned. Also JSON-LD is interesting.
Namespace http://en.wikipedia.org/wiki/Namespace http://en.wikipedia.org/wiki/Xml_namespace Ontology http://en.wikipedia.org/wiki/Ontology_(information_science)
RDF http://en.wikipedia.org/wiki/Resource_Description_Framework http://www.w3.org/TR/rdf-primer/ http://www.w3schools.com/webservices/ws_rdf_intro.asp RDFS http://en.wikipedia.org/wiki/RDFS http://www.w3.org/TR/rdf-schema/ http://www.w3schools.com/webservices/ws_rdf_schema.asp OWL http://en.wikipedia.org/wiki/Web_Ontology_Language http://www.w3.org/TR/owl2-overview/ YAML JSON Gellish http://en.wikipedia.org/wiki/Gellish http://sourceforge.net/apps/trac/gellish/
Turtle JSON-LD http://json-ld.org/index.html# http://www.w3.org/TR/json-ld/
Tracker Strigi Beagle
[ ] = TODO [%] = WIP [X] = DONE [ ] 21nov2013 Start designing basics of Idan using YAML [ ] 21nov2013 Continue API development in C++ [X] 21nov2013 Examine Gellish's extra fields for triples, e.g. fact/question/opinion, see how I can have them in Idan [ ] 21nov2013 Finalize the architecture basics, to make sure the API matches requirements [ ] 21nov2013 After architecture basics are final more or less, list components: [ ] 21nov2013 API to write graphs to file and read from file [ ] 21nov2013 API to efficiently update file with changes, e.g. see how Gedit and others update files: rewrite all or just changes [ ] 21nov2013 Decide where SPARQL / similar language can be used - on top of repos or just for database repo [ ] 21nov2013 CLI tools [ ] 21nov2013 GUI tools [%] 21nov2013 Go over CherryTree document, see what I can use, maybe make a file here to track migration of data from there to here [ ] 21nov2013 Create an automated task solution which doesn't require putting all tasks in one file [ ] 21nov2013 Create a script which extracts tasks from files in the progress folder [ ] 21nov2013 Learn bash scripting [ ] 21nov2013 Learn shell programming [ ] 21nov2013 Learn coreutils [ ] 21nov2013 Write makeclass in Bash for practice [ ] 21nov2013 Make the tool read patterns from a file, so that new ways to mark TODOs in files can be easily added [ ] 21nov2013 Split the research files to separate research for each component and add them to respective folders [ ] 21nov2013 Find/write scripts which generate table-of-contents from titles in my files, so it becomes possible for GUI to use anchors to run a GUI table-of-contents and help the user easily manage long files. If I make the TOC manually in plain text, it would become tedious and difficult to manage the TOCs over time, and they're not interactice anyway. So make scripts for that. The GUI would use them, but there's probably no justification to use C/C++ directly. A script in Bash/Perl/Python will probably do. [ ] 21nov2013 IDEA: A tool which lists the "chain of documents" I work with and the current one and the status and what to do and what to do after that, etc. to help me keep context and remember where I am, both in real time and when continuing where I stopped last time
My next tasks are writing parsers and serializers for Idan and for Kort, and formalizing the Kiwi ontologies. This leads me to the first Partager application. It must exist in order for problems and needs to show up, and to have a practical example of things in real use.
The idea is to have one desktop database accessed via D-Bus (or k-dbus) which GUI applications can then use for anything they wish. It will be an experiment. The actual first GUI application I’d like to have is a file/info browser which operates over all the visible files in the home folder, or over a subset of them. Later we’ll see exactly what this application will do and how. It’s also possible to use a simple file for this, as long as it’s the only application using this Repository.
Another option is to have an app which simply uses a small file, e.g. make a movie collection manager like the one I tried, but with a full ontology and expansion of the ontology would be supported transparently thanks to Smaoin. It’s a small simple app, easier than a whole desktop info manager.
In order to write a parser/serializer for Idan, I need to formalize the syntax. Here it comes, more or less. I’m assuming UTF-8 characters as atoms, not ASCII. Also, I’m starting by using just the Smaoin Idan files as reference, and later I’ll go over all the plans and the i18n file in rdd-wiki and make sure I didn’t forget anything.
This brings a question: Does a comment have to be on a separate line, or can it be at the end of a line? I’ll need to examine all the docs to answer this well. Let’s start with just a simple subset and expand gradually.
For now I’m omitting the whitespace between components, because it makes BNF ugly. But basically the idea is that all things that aren’t required to be attached can have any whitespace between then: blank lines, space, tab and so on. For the full list see here: https://en.wikipedia.org/wiki/Whitespace_character.=>