13 February 2018 (Tuesday)—10:57:17 PM
• Make it so you can use || to delimit names/aliases from descriptions.

31 January 2018 (Wednesday)—2:27:06 AM
• Make it so choosing secondary nodes can cause variables in the database to change (relations included—not just such as parameters). People need to be able to move (rather than just the reader). OR make something different than relations that is meant to change.
• Make it so there's a command-bar on the website (which one may optionally use instead of clicking).

30 January 2018 (Tuesday)—5:15:31 AM
• Make it so you can merge nodes (so one becomes an alias of another). Make it so the old number is also retained (though depreciated): the first one in the list of numbers is the correct one to use.
• Start making disambiguation nodes. Do this just by creating a disambiguation context and using it.
• Make it so you can turn or translate a text document or tab or selection of such, of Shule into a desc attribute.
• Text style shortcuts and image shortcuts added to the line-by-line data entry for the desc attribute of nodes: /italics/, *bold*, ^strikethrough^, and _underlined_. CHECK
• You can make links to other nodes (with optional other text) in the desc attribute of node objects: [[nodeName\optional text]] (I'd have used the | character, but it’s used as my data entry delimiter). CHECK

27 January 2018 (Saturday)—12:53:54 AM
• Make it so you can customize colors for the HTML export.

26 January 2018 (Friday)—6:56:35 PM
• Add support for adding images to node attributes and relation link attributes. Just let images have unique names, and have them all in an image folder, and let users use HTML in the document. Also, have another method that will translate a given text body into HTML, according to rules I’ll make.
• Add support for linking to other nodes in node attributes (translate the names used to link to their ID numbers upon saving the attribute, if numbers aren’t initially given).
• Integrate with Shule.

23 January 2018 (Tuesday)—11:37:08 PM
• Make a data entry method for entering desc and other relation link attributes for multiple secondary nodes with the same primary node and context:

&relation link attribute|watermelon|breeds|desc

Dust Bowl Seed watermelon|Related to Georgia Rattlesnake
Neapolitan pepper|Very prolific

17 January 2018 (Wednesday)—8:41:42 PM
• Make it so alias names work with the concat character, without making the concat character work with extra primary nodes, too. CHECK
• Make it so you can add relations in data entry as usual, except so that you can do a unique context per primary node. CHECK
• Update the documentation with the new format for adding relations: primary1|context1|cross1||primary2|context2|cross2||etc.|||etc. (line contexts are the same)

15 January 2018 (Monday)—7:08:14 PM
• Make it so you can make nodes that belong to other nodes (for instance, a unique wantlist node for each user nodes). For instance, if Shule is a node that is a user, we should be able to make a wantlist node specific to Shule.

13 January 2018 (Saturday)—9:42:09 PM
• Make it so you can name a group of nodes and use it in the data entry (having it treated the same as if you had typed out all the nodes).
• Now you can add pepper and Capsicum annuum secondary nodes in one go. Do it.

12 January 2018 (Friday)—2:46:38 AM
• Make it so you can add multiple primary nodes on the line that indicates commands for data entry. That way, it’ll make a relation with each primary node with the secondary nodes. CHECK
• Make it so exporting deletes the old stuff first instead of just overwriting it. CHECK
• Make it so aliases are ignored properly when they already exist (in the data entry).
• Make it so you can add text body for a specific relation. This will allow you to give grow-out reports and such. (This is one thing that relation link attributes—lattr—are for. Program it into the export.)

9 January 2018 (Tuesday)—9:59:37 PM and 10 January 2018 (Wednesday)—12:16:03 AM
• We have subjects, verbs, and direct objects. We need indirect objects: e.g. `Shule` `grew` `German Pink tomato` in `2015`.
• Make it so you can export nodes that don’t actually exist—make some queries, and have articles/contexts/relations autogenerated from the results. Make it so you can make those in advance.
• Make it so you can make relations in a new way (rather than tomato|includes\n\nlist of tomatoes, do &misc relation|context\n\nsome tomato\nsome watermelon\nsome eggplant, etc.—anyway, this is uses the last lowercase words of the secondary node to indicate the primary node. CHECK (but you can now do the same stuff from the regular way of making relations, given the syntax for it)
‣ Make it so you can do this when you’re adding relations otherwise, too (so you can add both/two relations in one step).
‣ Add documentation.

5 January 2018 (Friday)—1:40:06 AM
• Make it so you can specify an arbitrary order for secondary nodes.
• Make it so adding a context to a node can automatically pins the node with something. For instance, Idaho capital is Boise should automatically make Boise is a capital.

3 January 2018 (Wednesday)—1:19:04 AM
• Make it so disabling inheritance for specific pins actually works.
• Make it so you can specify only one of the parent’s secondary pins for inheritance to travel through.

30 December 2017 (Saturday)—7:36:04 PM
• Make a method to gather all the ancestral pins of a pin, and then use the pin() method to all the nodes in all the pins with those pins. Use this to replace INHERIT_ANCESTORS, INHERIT_DESCENDANTS and such. Same for disinheriting. Don’t use this method in make_relation or remove_relation.

29 December 2017 (Friday)—6:43:57 PM
• CHECK Make a method that searches through all the nodes that meet certain criteria, and then removes them from a certain set of relations (if they’re part of those relations). This is meant to replace the disinherit methods (which seem like they may be too error-prone from the user’s perspective; they may remove things you’ve added after the fact that you want to remain). The methods I made are pin() and unpin(); unpin() replaces DISINHERIT (and pin accompanies INHERIT).
• Removed the disinherit methods.
• Add data entry methods for pin() and unpin(). &&&
• Make data entry methods for adding relations without inheritance.
• Make it so you can save rollbacks before adding relations with inheritance, from the data entry methods. (Just in case you mess something up.)
• Fix it so if nodes have been pre-made, inheritance with them still works. Fixing. If you make #Solanaceae include Solanum, Solanum doesn’t inherit anything, but plant, tomato, and each tomato do.

1 December 2017 (Friday)—11:22:00 PM
• Add set_pin_ancestor_inheritance and set_pin_descendant_inheritance to data entry (CHECK—I made lots of commands for this).
• Fix bugs relating to the above methods of wikiweb.py in such as DISINHERIT_ANCESTORS and INHERIT_DESCENDANTS. CHECK (just needed to check to see if the secondary pin was enabled for inerhitance).
‣ Keep checking for bugs.
‣ Fix bug that makes it so both descendant and ancestor inheritance have to be enabled/disabled for either to work.
• Check INHERIT_ANCESTORS/DESCENDANTS to see how it works with relations that don’t allow inheritance. (It doesn’t work properly.)
• Make it so remove_relation and disinherit methods are separate. You may want to do that with make_relation and inherit methods, too.
‣ With disinherit descendants, make it so removing (plant, includes, Solanaceae) will cause that no things pinned with (Solanaceae/Solanum/tomato, is a) will be plants.
‣ With disinherit ancestors, get all ancestor pins (and only ancestor pins). Unpin them all. You actually don’t do this to the primary node (but rather to its parent): Sweet Orange Cherry is a tomato (it removes tomato and everything tomato and its ancestors are from Sweet Orange Cherry). You don’t have to look at these as ancestors. It just disinherits everything from something that’s pinning it.

17 November 2017 (Friday)—2:47:34 AM
• Fix DISINHERIT_ANCESTORS and DISINHERIT_DESCENDANTS CHECK (I think it tries the crosses make it try to do this twice; this is why I check to see if they’re related at the end of both methods)
• Removed implied pins. They were too error-prone and complex.
• Made it so pins are inhereted, and so it does it naturally. It uses recursion to gather all the applicable ancestral/descendant pins, and then it pins them (this is currently only done when making relations). Ancestor/descendant pins are to be removed when removing a pin, but there are bugs (so, it doesn’t work, yet). I gave pins variables that indicates when they shouldn’t be inherited.

16 November 2017 (Thursday)—8:27:50 PM and 17 November 2017 (Friday)
• Make it so in data entry instead of doing descriptions by the default after | have it do alias names. CHECK

15 November 2017 (Wednesday)—3:00:48 PM and ~16 November 2017 (Thursday)—12:54:06 AM
• Debug the new disconnect and del_context methods and add pin removal to remove_relation (that should be the only main place that uses unpin_implied. Pin removal should only apply to the node that you’re removing a pin from (the implied pin removal pins should only be removed from that node).
• Make a better name than implied pin removal pins.
• Pin removal pins should be placed on further back in the pin ancestry more often than in the descendancy. I mean, if you remove plant breed, you’ll want to remove tomato breed. If you remove tomato breed, you may not necessarily want to remove plant breed. So, when you’re automatically adding pin removal pins, make sure to add them right (I don’t think they’re done correctly right now). So, in imply_pin, the pin and implied_pins parameters should be switched around for the pin removal; you can also make it so when you remove the original implied pins that it removes the automatically added pin removal pins, too.

14 November 2017 (Tuesday)—3:14:08 PM
• Allow nominative and accusative names for nodes. For instance, you might want a primary node to display a different name than it would if it were a secondary node (e.g. if I is a nominative node name then me could be its accusative node name).

8 November 2017 (Wednesday)—4:42:40 AM
• Make it so you can imply pins and pin removal from the data entry method.
• Make it so when you come upon a pin, it checks to see if the node and context still exist (and deletes the pin if either one of them doesn’t exist).
• Document implied pins.

26 October 2017 (Thursday)—4:47:42 AM
• Make it so disconnect also removes associated parent nodes. (This takes care of the need to do it when deleting). NOT NEEDED (it already deletes context.nodes[node_name], which contains the parent nodes); it also already removes the relations caused by those parent nodes (it removes all relations).
• Make it so if either primary nodes or nodes that are parent nodes are deleted, that the parent nodes are deleted. I mean, if food is a parent node for (fruit, is), then if you delete the food node, it shouldn’t still be a parent node for fruit. Deleting food won’t do this automatically like deleting fruit will. CHECK (although they’re deleted as they’re encountered, rather than deleted when the nodes are deleted, for the sake of efficiency). So, an optimization method might go through all the contexts and check all their nodes’ parent nodes for ones that have previously been deleted.
• Make it so remove_relation/unpin throws an error if you attempt to remove a relation that should be removed by removing a parent node. Or, just make it so you can have manual ones be removed (and so you can refresh the parent node to bring them back); this is how it is now.
• Make data entry methods for refresh_pin(), add_parent_nodes(), and remove_parent_nodes().
• Make add_child_node and remove_child_node methods. This will allow you to add/remove parent nodes to/from multiple primary nodes at a time, which might be more useful.
• Finish debugging add_parent_nodes/add_child_nodes, etc. They have bugs and may need to be re-written entirely.
• RESTARTED (the above). Saved backup and reverted back to mostly before I started on this entry. On the real file, debug get_pin_ancestors and get_pin_descendants.
• Find a way to deal with a pin as with a tag. Maybe add the parent node pin information to either the node itself, or the project (rather than a context; contexts are used for other things, and that makes it complex).

20 October 2017 (Friday)—4:03:38 AM
• Add inheritance to primary nodes. (So secondary nodes are also secondary nodes to whatever primary nodes are secondary nodes to with the same context). Or, make it so you can manually add parents to a node. Look at forum.py's Tag class for an idea as to how to implement this. I mean, a zucchini is a squash. A squash is a cucurbit. A cucurbit is a plant. Therefore, a zucchini is all of them. This isn’t a matter of context inheritance (although I’d like to make that possible, too).

4 October 2017 (Wednesday)—11:46:14 PM
• Make it so data entry doesn’t allow dashes, em dashes and spaced en dashes directly before an apostrophe if formatted quotes are enforced.
• Make the data entry method able to require formatted quotes (instead of converting all formatted quotes to unformatted quotes); i.e. disallow regular quotes.
‣ See dp_wikiweb.py’s DPProject.format_chars() method, and finish.
• Allow it to convert unformatted dashes to formatted dashes.
• Made it so sorting sorts does natural sorting (while grouping in the way I desired).

29 September 2017 (Friday)—7:13:07 AM
• Made it so you can (from a module that imports wikiweb) replace Node/Relation/Context classes in wikiweb with new classes that inherit from them.

27 September 2017 (Wednesday)—12:00:33 AM
• Make regex functions for renaming attribute keys and changing attribute values (particularly for things like title and desc, but for all keys and for all string-based values).
• Mention that when extending wikiweb, anything you want saved/persistent should be in project.a or other variables that were already in wikiweb. (NOT REALLY; while you can save variables that way, you can also help them persist by putting them above the parent class’s constructor call) in the child class’s constructor.
• At release time make sure to also release a version that doesn’t include the user functionality built-in. (Outmoded; thanks to an impression I got, that version doesn’t exist anymore; so, it’s not built-in—but I did make a class that imports wikiweb that extends it with the User functionality.
• Add built-in variables for title and desc/body.
• Add User.triggers functionality to Project.visit().
• Make triggers that happen at certain times/dates and such.
• The reason I wanted to add users to wikiweb is for continuity (self.unuo is more similar to self.nnno than self.a["unuo"] is. I could always make it so you can a property that makes it so self.unuo seems to be self.a["unuo"];

26 September 2017 (Tuesday)—2:58:36 AM
• CHECK (debug) Make it so you can make aliases (for nodes) in wikiweb.
• Make data entry commands for users and aliases. Document these features.
• Passwords are hashed, now. Make sha3_512 the default after Xubuntu 17.10 is released.

25 September 2017 (Monday)—6:57:28 PM
• CHECK Instead of having only one current node, there should be a current node and such for every single user of the database (so, hypertext fiction should be able to be multi-reader, and games should be able to be multi-player, whether or not it’s only one reader/player at a time).
• Make a system to queue commands to be executed by the project in a specified order, in order to allow multiple users to use one project at the same time. Make a class that interfaces with the project and queues stuff to be executed.
• Instead of dealing with all kinds of threads, just have a program that evaluates commands in a text file. Have the other programs append text (commands queued in the file for execution) to the file (so, users aren’t even using wikiweb—they’re just writing to a text file, which is read by the software using wikiweb). In fact, we could do multiple files to avoid having to worry about them accessing the file at the same time. Just delete each file when done. We don’t even have to use a multi-threaded program. We can just have multiple instances of the same program, if we want (instances of the same program for writing text files). That might take more RAM, though.
‣ Have one text file per connection. Have it be named the ID of the user. The program parsing the commands will periodically search the folder for files. Now, we just need a way to submit text.
‣ Have it save the database when idle for a certain amount of time.
‣ Only do one file at a time (and do every command in that file at a time). Then delete the file. It’ll be recreated when a new command is made.
‣ Or, just do multiprocessing or multi-threading.

22 September 2017 (Friday)—2:35:38 PM
• debug dp_wikiweb.py’s pro.visit() method.
• Make a command-line program that lets you traverse the wikiweb (using the visit method—and potentially others). partial-CHECK (the method is done; the command-line interface isn’t; debug)
• Make it so you can over-ride skipping hidden nodes for a specified visit. CHECK
• Add documentation for triggers and visit.
• Make it so you can convert trigger specified methods to JavaScript on export (instead of having to write them in JavaScript). Not all methods will be able to convert, of course (unless we convert the whole database to JavaScript).
• Program in commodities. Allow nodes to be commodities (have a commodity attribute to represent their amount as a commodity, and make sure the ‘amounts’ or number objects know which node they belong to).

21 September 2017 (Thursday)—6:47:14 AM
• Integrate with Shule; replace old similar functionality (i.e. file indexes and database; use wikiweb in their stead); fix up Shule (remove scripture lookups; keep scripture references; fix up that sub-menu with dangerous menu items for those who don’t understand them; work out the licensing; remove any things that require me to have a certain license); make an installation file for Shule; publish Shule.
• Make it so a starting node must be specified.

16 September 2017 (Saturday)—11:45:44 PM
• CHECK Fix the errors by &&&&& and the &&& at the top. -= and .remove() aren’t working properly. It’s trying to use a set as a key to a dictionary when removing a secondary node from a relation.

13 September 2017 (Wednesday)—6:51:04 AM
• Make a way to alter relation attributes from the data entry method.
• I made it so you can hide nodes, contexts and relations, and so you can set and check attributes more conveniently.
• NO NEED (but CHECK for functionality) Make a class that like datetime with your chosen format for the string representation (instead of the default).

4 September 2017 (Monday)—8:35:45 PM
• Make a data entry command for adding html update parameters to a secondary node of the relation. CHECK

24 August 2017 (Thursday)—11:43:15 PM
• CHECK Make a JavaScript function that takes parameters to manipulate the values of the current URL parameters (while they’re in dictionary form), convert them back into string form, and submit them to the next site. Have all this be called with one function (with the arguments for manipulation) at the button press.
• Make Python versions of what I’m doing with JavaScript (and make it so you can convert it to usable JavaScript with Transcrypt). I mean, make Python functions to be executed upon following a relation link.
• Make a command bar for typing commands.
• Find out how long a URL can be (if they can be super long, you can have a lot more stuff going on).
• Find eBook formats that use some kind of script for calculations and variables—lacking that, make your own format that does use Python.
• Make it so relations can be hidden. CHECK (This is done in attributes; not in wikiweb itself; wikiweb doesn’t have a current node or a viewer in and of itself)
• Make it so only cross-relations can be hidden, if desired. That way, you can go one way, but you can’t return (but they’re still connected).
• And/or make it so relations can be non-traversable (meaning following them doesn’t take you to them, but rather it executes functions or whatever). Then you can make commands that are nodes that don’t take you to a different node. (So you can get an object in a text adventure without going to that object as if it were a room.) This should probably be able to be set in the context object itself for all relations of that context. Of course, in order to make this, we’ll need to make nodes traversable in the first place.
• Consider making a JavaScript version of the wikiweb module (then you can do everything from the same HTML page, and make it give you a password, however long, that encompasses the saved data, which you can re-enter later; the saved data could be the totality of commands you've entered, with the random elements being forced as what they actually turned out to be; you can have a parameter that allows for a forced value instead of a random value for the functions that are random in regular usage). Or, it can just go through and report what is where and what stats are what, and parse them back when you resubmit the data.

To make your own e-book format, you should define a bunch of things:

• Allow for basic HTML and CSS. Stylesheets should be optional (and not what the majority of people use, as the default style should be sufficient for most purposes—certainly not all).
• Make it so you can convert word processor documents to this format easily. Convert them to HTML, and then convert the HTML files (that’s probably the simplest way, since we won’t have to have libraries for manipulating each format). Try to support Microsoft Office, Google Docs, and LibreOffice, as well as rtf files.
‣ Ensure that the user is prompted to remove any annoying stylesheets imposed by the document that will get in the way of the user’s experience (and customization of the e-book).
‣ Find libraries for converting word processor files to HTML (I’d love for the end-user just to export it to HTML, but people may want to just convert their .doc files right away).
• Have tags for such as page breaks, custom table of contents (not a custom static one, per se, but dynamically updated as chapters are updated) … .
• Add functionality to make the format compatible with visual novels (e.g. transitions, etc.). This should make it so you can export the project to a Ren'Py visual novel without having to do any fine-tuning afterward.
• Add functionality to support point and click games and text adventures (e.g. so you can add and customize commands). If commands are nodes via relations, then functions that run after them and such can be run with the functions in the relation attributes. When you click a command, it may prompt for the parameters (which you could choose from a list, if it's not too long).
• You need to be able to click on relation links that don’t actually go anywhere (they just do stuff).


22 August 2017 (Tuesday)—9:06:55 PM
• Have the project have an attribute with a list of URL parameters that should be submitted every time you follow a link. (CHECK for the ability to have such attributes existing.) Have a way to define which parameters need to replace a value, which ones need to increase a value and which ones need to decrease a value.
• You need to be able to associate URL parameters with each item in Relation.node_objects. Maybe change it from a set to a dictionary with node objects as keys and a dictionary of attributes as values (with one of the attributes being parameters). CHECK I made a new datatype that inherits dict but has the basic functions of a set. So, I just had to change it from set() to an instance of my new class.
• Make methods to encode/encrypt and decode/decrypt URL parameters (so users won’t be able to see and change what they are willy nilly as they go). You could use base64 (or let the user choose which way to do it).
• Make it so the methods that manipulate attributes aren’t part of wikiweb. CHECK Make a separate module for such as what will use HTML export. CHECK

21 August 2017 (Monday)—8:46:40 PM
• Make methods to get the current html parameters and for adjusting and sending them.

19 August 2017 (Saturday)—10:31:05 PM
• Redo regex node matches and regex context matches in Project.data_entry() to make it so you don’t have to use a delimeter with no ability to escape it (but just do it the way of typing out a Python dictionary as with regex rename and such).
• Make HTML export
• Integrate into Shule.
• Finish the documentation. CHECK (for now)
• Make a hypertext fiction IDE using this.
• Look at how it can work vs. other methods with text adventures.
• Add more functionality useful in text adventures (e.g. implement titles; make them the same as the name if the title isn’t specified).
• Make it so you can make nodes commodities that can be traded among other applicable nodes (each commodity has only one node, but there are multiple of each commodity, usually). Each commodity could be tracked by the system itself (who has it, etc.) instead of by each node (this way, we can ensure that there is a specific amount and still know what it is without doing all kinds of calculations once people have been trading for a while).
• CHECK Make it so you can enter a single pin (not in a list) where it lets you enter a list of pins.

18 August 2017 (Friday)—12:49:14 AM
• Make a regex disconnect method that disconnects every node that matches a certain regular expression. Same for delete. CHECK (context versions done, too, and all are added to Project.data_entry(); more context methods added to both, too). Debug.

15 August 2017 (Tuesday)—2:17:00 AM
• Think about doing the objects directly everywhere. Access names through the objects (objects should be the only place they exist, well other than a dictionary to help access them by name). WORKING ON THIS. This simplifies the code a lot. The IDs were kind of redundant if the program was the one to be using them. Now, the IDs are just for people and the program uses objects for keys and/or values in dictionaries. This should make it easier to program family trees.

12 August 2017 (Saturday)—4:12:54 AM
• Scratching dict_relations and such due to too much overhead. Make it so the end user can add linked list tree structures to node attributes instead.
• Make it so the end user can add external functions to use in Project.data_entry(). Make one such function designed to do stuff with tree structures in node attributes.
• Or, add indirect objects to the sentence. E.g. 'is mother to'=context; 'Sam'=node; 'Veronika'=node; 'Erick'=node; Veronika with Erick is mother to Sam (this means Erick is Veronika’s husband).
• Make it so adding some contexts automatically adds others (although it may be to certain other nodes in the sentence that it affects, and not just the primary node).

11 August 2017 (Friday)—4:20:54 PM
• Instead of making Node.dictNode and such, make special kinds of relations that take certain arguments. For instance, you can have one that allows for pairs of nodes wherein one of each pair is the mother and one is the father. It should be handled at the relation level, since you’ll want to be able to relate things in multiple and flexible ways.
• Make it so you can use Project.data_entry() to add trees using Node.dict_relations without having to do everything manually. This is useful for making family trees (not just for humans, but I also intend to use it for taxonomy, F1 hybrid parentage, etc.).
• Make it so each dict_relation is automatically named when using Project.data_entry to make them (and associate each with its parents, and relate each with a regular relation with its children).
• Make it so nodes and contexts are displayed by titles (not by names, unless titles are absent). Titles may be unique per relation of the same context.
• Make a method for merging two nodes.

contexts: member|relationship, and parents|children

&mdr|dict_context (member)

Green King F1|mother=Green Giant|father=Golden King of Siberia

Autoname the couple article 'dictGroup1'.

11 August 2017 (Friday)—3:06:47 AM
• Make methods to manipulate and allow for data entry for Node.dictNode, Node.setNode, and Node.listNode. Especially keep in mind family history trees for Node.dictNode. Node.setnode might allow you to make a single node to represent a group of people (other nodes) who won an award together, or who worked on a project together. &&&finish
• Make it so you can set the default context from the data entry text.
• Make import/export methods (for importing and exporting nodes/contexts/relations and/or projects)

10 August 2017 (Thursday)—6:57:12 AM
• Make it so each relation has a constant ID counting system for its nodes CHECK (relative_node_ids). This way, you can have IDs specifically relating to all tomatoes (without any other articles incrementing the ID numbers, making them larger than necessary). These IDs aren’t used by the system as the regular IDs are.
• Make a method that scans the mstring for obvious errors (e.g. missing nodes and contexts) before attempting to parse and execute it. Also, it should scan for things you should be warned about.
• Add node objects and node IDs to the types you can enter for '&attributes' in Project.data_entry(). Node names should not be stored, since they can be changed. All the pertinent methods are in the Project; so you don’t need to know the node name from the object itself. Use Project.nonn to get the name from the object. Nodes contain data—not methods.

--------------------
Initial notes:

Make a system where people use software to manipulate their own database (not really a database, in this version, and perhaps not required to be; it’s just a pickled file). That way, they use the processing power to do all the calculations on their computer (not the server), and they can upload it online to update it online (sync it) at their leisure (although number of uploads per amount of time might be limited based on available bandwidth and need for efficiency; the software should be able to schedule uploads, whether or not how often you can upload is limited, since some people may not want something to be available until a certain time, and they may not want to keep track of when to do it).

You don’t need users and permissions on the software that the end user is using, since there’s only one user per database. However, we might need some privacy settings to allow only certain people to be able to view certain articles, only logged in users, etc. The website online is the only place people should need to enter usernames and passwords (unless the software allows them to do so for uploading).

This should be workable since multiple people won’t be editing a single database at a time. Plus, if the system gets compromised or corrupted, people will still have their own databases.
Users should be able to have more than one database.
Suggested edits are requests that you mirror someone else’s work are intended. Perhaps you won't need permission to mirror other people's work, so long as that’s part of the license people are required to use.

For content policing, the users should take care of that, for the most part, with votes, reporting, etc. So, the software may need to receive commands from the server at times, at least for moderation purposes (although it doesn’t rely on that; this is to help prevent the user from accidentally uploading banned stuff again). Or, the banned version online could be compared with it upon uploading to prevent it from making it back.

Disambiguation can be done with relations. Make a disambiguation context. This way, an article can be a disambiguation article and a regular article at the same time, if desired (although that’s not the reason for it).

Query methods are primarily online only. However, they probably should be made for this, too (but they won’t be exactly the same).

Make it suitable for hypertext fiction/games. Allow for variables, methods and random elements.

Make it so you can make Nodes contain an amount of tradeable goods representative of that Node. The Node is the system here. Goods are traded between nodes and users. This is an online thing. A wiki owner may set prices or conditions one must meet in order to obtain a portion of goods.

Allow each kind of object to be able to take a stylesheet of sorts (not HTML, per se).

8 July 2017 (Saturday)—7:19:03 AM

&&&Program inheritance so we know that Yellow Doll F1 watermelons are cucurbits and such, without having to follow a line of links. I mean, marking it as a watermelon should automatically mark it as a cucurbit, as long as watermelon is a cucurbit, and inherits that.

Make it so you can add good numbers and trade amounts between the node and users.

&&&Debug all the remaining methods of Project.

&&&Make query methods (or query->action methods). Make it so you can find all tomatoes that end in ‘ F1’ and make them F1 hybrids. I mean, find all articles optionally with a certain relation and give them or take away another certain relation (if they don’t already have it).

&&&Make aliases.

&&&Make it so you can make multiple nodes with the same name (within the head node of that name).

&&&Make it so ID numbers use a base 36 counting system (0-1, a-z). I would do 62, but not everyone who would use these numbers would likely use the casing system properly.

&&&Incorporate this into Shule and make it so you can select text and insert it into the database (via such as Project.data_entry_breeds()).

DONE: Make more kinds of data entry methods, and a text parser to identify which kind of method is required for the selected text.

&&&Make it so you can export the database to HTML, use randomness, use symmetric encryption, use variables, methods, etc. (The software should be useful for more than just interfacing with the website. People can make games, hypertext fiction and stuff.)

&&&Make it so you can export it to a server-side CherryPy script or something.

13 July 2017 (Thursday)—1:57:37 AM

The name pin is still used despite context and relation being in place. For example, a node when used as a category would be an pin. pin doesn’t refer to the relation or the context, but rather to the node that uses them in relation to other nodes.

Glossary:

• Node: A node is what contains the data in the system. A node may be an article, or anything that holds content.
• Context: A context defines words used to determine how nodes may relate to each other: e.g. ‘is a’, ‘includes’, ‘lived in’, ‘lived here’.
• Relation: This links and cross-links specific nodes with a context.
• Pin: A pin is a node that uses a primary context to be able to relate to other nodes. A primary context is relative to what the speaker considers to be the primary one (well, it’s kind of like the subject in a sentence; the noun is capable of being either the subject or the direct object, but what it’s doing determines which it is). For instance, if you create a node called ‘tomato’ and relate it to other nodes with a context (e.g. ‘includes’), then tomato (with the particular context ind mind) can be thought of as a pin, and the other nodes are pinned. Pins are not separable from a specific context. The same node with a different context is a different pin.

8 August 2017 (Tuesday)—5:19:21 AM
&&&&Make documentation for how to use Project.data_entry(), including all the commands. Integrate it into Shule so that you can make wikiwebs with it more naturally!
&&&&Make it so you can add attributes (any attribute) to nodes via Project.data_entry(), including "desc".