Wiki Structure and Linking

[Scot]

Hello Everyone,
As an exercise I would like to collate data from a number of areas/topics and relate it in some kind of hierarchical structure. Maybe a Table of Contents, Lists etc.
My problem is that I’m not sure which way I should structure the wiki in order to cross reference / query the data.
The data will consist of …

• People / Company/Names/ Position / Interests/ Group Membership/ Policies or Decisions

• Companies/ Related Companies (Owned or otherwise)

• Quotes or References (Memo, Meetings, Letter etc)

• Photos (External Links)

I have been reading the post Make [[links]] more powerful - #11 by TW_Tones

A number of plugins such as Shiraz (Dynamic Tables and Advanced Search for Fields) TWCrosslinks, xlist , Kin Filter and other tips to transclude and link to tiddlers have given me some ideas

I would like to know the thoughts of the more experienced users of TW on how this could be achieved or setup and which methods you currently use.
Obviously before I jump in at the deep end and find I’ve taken a wrong turn and wasted my time

Any suggestions would be very welcome.
Scot

[stobot]

Ah, the age old structure question… It’s often asked, and heavily debated. I love the question because it highlights that the system itself is so flexible, even deciding how to structure things is hard with so many choices!

Here’s my 2 cents after many years of using TiddlyWiki.

I use tags for objects or like where I’d use a table in a database. Meaning if it was a database, I’d have one table for People, one for Companies, one for Photos etc. Other people also use fields for this, but I like tags for this for some other conveniences built into TiddlyWiki. Each tiddler with the same tag will be treated the same, it’ll probably have a template, have the same fields, etc.

I then use fields for all other relationships between those “objects”. So, if I have the person Bob who works for the company Microsoft, then on the tiddler Bob, I’d have a field “works-for” with value “Microsoft”. I’d usually link two objects by storing the relationship on the “one” side of the “one to many” relationship. Meaning I’d do it the above way rather than have a field on the Microsoft tiddler called “employees” and store a list of the employees. That’s mainly because it’ll make programmatically editing, as well as querying a little easier downstream.

This structure (vs. something loose like links and backlinks) gives you the ability to relate two “objects” in multiple ways. In project management for example, there could be a task and people involved, but those people are all related in different ways - one is the owner, one is the customer, etc. I can write a “query” easily to tease any of those details apart.

Then everything else is a <$list filter=""></$list> from templates, to tables, etc.

[Charlie_Veniot]

Like facing a blank page or a blank canvas: just start writing or drawing.

Whatever structures fit whatever topics/categories/whatever, they will will all reveal themselves to you as you start seeing the bits and pieces in front of you and all of the intertwingularities between them.

You wouldn’t cobble a house together room by room this way because of the work involved moving door/window frames, etc.

But a wiki and what you put into it are all malleable.

Questions like “should I create each thing as a tiddler and have a list widget to give me the list of all those tiddlers right here, OR, type the list of all of them right here and then create links for all of them via square brackets?” Who cares right now? Start typing, figure it out as the growing pains creep in.

The processes vary as much as there are personalities and preferences (and how your sponge works), the data you’re working with, the goals you want to achieve, etc. etc. etc.

Of course, I’m ridiculously artsy-fartsy-creative and profoundly suffer from paralysis by analysis …

Whatever it is, give it what it needs as it needs it, and if it is a tomato seed and you are getting frustrated that it isn’t growing potatoes, time for a rethink …

[Scot]

Hi @stobot ,
thanks for your detailed example. The confusion tends to stem from using structured database systems in a company / organisation. Querying the database with SQL statements and having Tables to store the data.
I like your use of tags for objects / tables in database as a strategy and think that could be my starting point.
Defining all the relationships between the objects may be more complex. I liked the idea of Tobias Beer’s xlist for some of the relationships but it only works with two groups. If I had multiple relationships, I’m not sure if that would work.
Obviously, I’ll need to give it a lot more thought but both you and @Charlie_Veniot have encouraged me to get right into it.

[Scot]

Hi @Charlie_Veniot ,
thanks for your input, I have read your other posts on structured / non structured usage of TiddlyWiki. I like the way that you think, especially your use of JSON tiddlers but have not really seen a wide range of examples from others.
Recent examples on Recipes from you and others have opened my eyes towards them.

Whatever it is, give it what it needs as it needs it, and if it is a tomato seed and you are getting frustrated that it isn’t growing potatoes, time for a rethink …

This seems to be the approach to take. If nothing else it will be a learning experience. Nothing ventured nothing gained, In for a penny, in for a pound.
Thanks,
Scot

[Charlie_Veniot]

Many many moons ago, members of the software development team left our software development project once it was in production, and I remained to support the thing for the next 24 years, the team of me.

They had left without leaving a process for documenting the system, the operation/maintenance of it, release management, etc. etc. etc.

Nothing left for me but the old DMR P+ Methodology and guides for deliverables.

The potential problem with a process is one quickly finds oneself a slave to the process, it taking on way more importance than the goals, the actual work.

And everything was in Word documents. A pain to access, a pain to update.

Then I discovered Wikis in 2005, and I tossed process and guides out the door, and let needs and content guide the structure.

If of interest, I did start writing my thoughts as “Intertwingularity Mapping” process. A project I’ve put aside because I have way too many interests and nowhere near enough time. Check it out for reading material on sanity/insanity breaks. Aside from it being fun because, hey, it’s TiddlyWiki, it also got created via my “no process” process…

[Mark_S]

@stobot

I use tags for objects or like where I’d use a table in a database. Meaning if it was a database, I’d have one table for People, one for Companies, one for Photos etc. Other people also use fields for this, but I like tags for this for some other conveniences built into TiddlyWiki. Each tiddler with the same tag will be treated the same, it’ll probably have a template, have the same fields, etc.

This is the way.

…

[twMat]

I don’t have any great answer but I think the following aspects are worth noting:

Tags vs custom fields
The TW system treats tags differently from custom fields. I believe it is optimized to handle tags more efficiently, both when it comes to UI and internally:

One obvious difference is that tags are visible in view mode. So one consideration is if you really want to see/show that bit of information prominently. With that said, it is possible to manually customize to not show specific tags and, vice versa, to make e.g custom field values do appear in view mode.

Another difference is that tags - or I should say; the value of the tags field - are typically treated as items in a list by the system. This makes them easier to work with than a custom field holding a list, or multiple custom fields.

Conditional viewtemplates
If you are not already familiar with it: Your use case seems typical for where “conditional viewtemplates” would be very useful. This may not seem like it directly has to do with “how to structure” but it does because it has to do with how the data is presented and accessibility to your stuff. To name one thing relating to the above points about tags vs custom fields; conditional viewtemplates can be a way to display such custom field values.

Basically a conditional viewtemplate is a tiddler tagged $:/tags/ViewTemplate that contains a conditional listwidget, e.g

<$list filter="""[all[current]tag[Company]]""">...

Inside that listwidget you make that type of tiddler show type-specific stuff. And you control where this displays in the tiddler by clicking the $:/tags/ViewTemplate tag and dragn’drop it into position.

[Scot]

Hi @Mark_S @Charlie_Veniot @twMat @stobot

@Charlie_Veniot , thanks again for your examples. I have seen your Intertwingularity Slice’n Dice Wiki, your cv and products etc. before, but will read them again to glean how to achieve some of your features. There is a lot to digest.

Hi @Mark_S
thanks for confirming your approval of @stobot 's methodology. It gives me more confidence in how to approach the wiki structure.

Hi @twMat
I have seen and used examples of conditional viewtemplates having seen @Mohammad 's Scripts in Tiddlywiki — codes, macros, and solutions in TW
I also agree with your statement about tags being easier to work with than a custom field.

@stobot
thanks again for your reply and advice on the use of tags.
I will go with your solution and try and piece together the required information in a way that seems most appropriate, like Charlie’s no process, process.

Scot