From WhyNotWiki

Relations  edit   (Category  edit) This is not to be confused with Interpersonal relationships (category). This is a much broader, more general category than that. It is about relationships between any kind of object or thing.

Relationships  edit   (Category  edit) This has been deprecated by Interpersonal relationships (category) and Relations (category)

[edit] Which objects are needed / How they will be used within the wiki / Schema

topic objects

text_body column (foreign key to text body object?, nilable) (Or should that be done via a "has_text_body" relationship? That might be the purist approach. But from a performance standpoint, if 99% of topics have one of these, then it seems more efficient to just skip the extra join...)

Each topic probably has 0 or 1 text body objects (the text of the "article").

To allow a topic to be used as either an "article"/page or a tag/category:

has_tag relationship to another topic... (actually implemented as a has_and_belongs_to_many, because there are many topics, each of which can have many tags...)

By having relations in addition to topics (= tags = categories), I think it will provide a great deal more flexibility (compared to my current MediaWiki situation) and will reduce the number of categories needed. [To do: Elaborate]

[Number (category)]

For example, it will be much less tempting/necessary to have a topic/article in the singular (like Object) and then a corresponding category in the plural (Objects). Instead of putting all instances of "Object" into the "Objects" category, simply cause each instance of Object to have an "instance of" relation to the Object record!

But for some topics (Databases (category), ...), the plural form will still be the obvious choice for the topic name. So there will still always be that dilemma about whether to make the topic singular or plural. In Wikipedia, they tend to make most of them singular, which works great for encyclopedias, but I'm afraid on more "normal" sites, people will prefer to talk about things in the plural...

Maybe we'd just want to adopt a singular-only convention, though, since that would make a lot more sense when doing the "instance of" relations.

[Inflection (category)]

It would also be great if we could avoid the proliferation of other inflected variants (besides number). For example, do we really need topics for both "Anti-Semitism" and "Anti-Semitic"? Well, there is a difference, something can be about anti-Semitism without itself being anti-Semitic.

So we can either handle that with inflections or with relations. Let's take a look at each of those:

relations: Perhaps articles about anti-Semitism could be labeled with a "about topic anti-Semitism" relation, and those that actually exhibit anti-Semitic viewpoints could be tagged with some different relation, like "instance of anti-Semitism". In this particular case, we've completely obviated the need for different inflections. (How does that hold up in general, though? Need to study more examples/use cases...)

inflections: We would want the single topic "Anti-Semitism" to have various inflections associated with it. Then when we tag an article, we'd actually tag it with an inflection -- such as "anti-Semite" or "anti-Semitism" -- rather than with the topic to which those inflections belong. Then, when showing a list of articles for a particular topic, it would by default show articles having any of its inflections, but it would let you break it down by / sort by inflection if you wanted a preciser shade of meaning.

This actually seems kind of ugly and I don't think I like it as much. Doesn't seem as elegant or as semantic as the relation approach and it requires too much knowledge/exposure of the natural language used (the inflections may not be translatable to other languages!). It would probably be better to not tie so directly to the underlying natural language, and instead to use another kind of semantic encoding that would be easier to internationalize/localize.

[edit] Compound topics

(Move this out into Conventions??)

I don't want to be forced to create a new topic object/record any time I have a subtopic that I need to cause to be a subtopic of some compound topic. And yet, I am still undecided as to whether that is just a necessary fact of life that I'll need to just get used to, or if there is an (elegant) way around this problem.

"What's a compound topic?" you ask? Well, it's any topic that is really the intersection/merging/combination/compound of two or more other topics.

Also known as: Intersection categories (category) (but that name is hereby deprecated)

[edit] Examples of compound topics for which it seems excessive to create a separate new object

In many of these cases, it just seems like overkill (redundancy), because although we may want to search on this compound topic, and we want to classify articles/objects into that topic, often we wouldn't ever want/need an article for that compound topic (but what if we changed our minds? Maybe we should leave that door open...).

• Negative feedback loops (category)
• Plasticity of software (category)

[edit] Possible solution: limit to flat topics only, but use SQL to create the concept of compound topics during searching

A search for everything in "Negative feedback loops" and "Sociology".

where 
    (topics.include?('Negative') and topics.include?('Feedback loops'))
  and
    (topics.include?('Sociology'))

In that example, it didn't really make a difference that we grouped the conditions as we did... I imagine, however, that there would be some searches where this were necessary...? A contrived example:

where 
    (topics.include?('Negative') and topics.include?('Feedback loops'))
  or
    (topics.include?('Positive') and topics.include?('Reinforcement'))

[edit] Possible solution: a database schema and markup that supports the dynamic representation of said compound topics

database schema:

• articles table
  • has_and_belongs_to_many :topic_compounds
• articles_topic_compounds table
  • article_id
  • topic_compound_id
• topics__compounds table
  • has_and_belongs_to_many :topics
• topic_compounds__topics table (red alert: extreme complexity creeping in here!)
  • topic_compound_id
  • topic_id

markup

<compound_topic>
  <topic name="Feedback loops" />
  <topic name="Negative" />
</compound_topic>

<compound_topic>
  <relation:of of="Software">
    <topic name="Plasticity" />
    <topic name="Software" />
  </relation:of>
</compound_topic>
(??)

[edit] Examples of compound topics for which it seems reasonable to have separate objects

...

[edit] Power and expressiveness / Export as RDF

I expect that this schema/feature/"language" should be every bit as powerful as XML/RDF.

It is my goal that any object/subtree in the database should be exportable as an RDF document.

Mapping (this is really incomplete right now)....

[edit] Use cases / Templates

[edit] Software

If you tell it that this is a software application, then it might suggest the following relationships:

• has_problem / solves_problem
• has_feature
• etc.

[edit] Imagined interface

A list of commonly-used / likely-to-be-used-by-this-particular-article relationships is displayed in a sidebar.

You simply click on one of the relationships and a suitable New Relationship form Javascript-magically appears (expands into the page inline?).

Submit the form via Ajax and presto, the relationship exists!

It will now show up from the target object/article, too, if it is a 'bi-directional relationship.

[edit] Relationships are people too, you know!

(well, not technically people, but first-order objects...close enough)

Each relationship may have different fields that are used, so the form may look different according to which relationship you are creating.

Examples:

• Some relationships use the "weight" column
• ...er, can't think of any more right now, sorry

[edit] Using relationships for [taxonomy (category)]

Having the ability to create relationships between objects/records allows for much more expressiveness than MediaWiki allows.

In MediaWiki, the only way to express a relationship is with a subcategory. For instance, I couldn't explicitly say that "Why?" is a kind of "Question". Instead, I'd have to create a subcategory "Questions" called "Kinds of questions" and make "Why?" a member of that. Requiring you to do it that way makes for a bunch of extra categories whose sole purpose is to describe relationships. Not only is it an unstructured way to store that information, it also results in tons of useless "intermediate categories" and it makes people less likely to express relationships because it's so much work...

[edit] Article metadata

Parent articles: Wrinkle, Relations

Taxonomy  edit   (Category  edit)

See also: All topics are containers?