support citations

Idea

support citations+status

support citations+priority

support citations+tag

 

support citations+issues

Wikirate.org specifically (and Wagn in general) needs a way to support citations.

 

In simple terms, this means producing an end result where there is a superscript number (in hard brackets a la wikipedia?), and that number can be clicked to see the citation somewhere outside of the body of the text.

 

Ideally we'd also like to be able to make use of typical wagn patterns:

  1. we should be able to reuse sources (without a bunch of cut and paste)
  2. we should be able to style the citations however we like (and different ways in different contexts)
  3. we should be able to query the citations even without looking at the full text
  4. we should be able to query citations from multiple cards at once
  5. we should be able to further restrict the citation list based on standard search criteria.
  6. we should be able to query all the cards that cite a given source

As discussed below, some these introduce some complications, but most are quite addressable.

 

 

support citations+solution

"cite" view

Squirrels are from Antarctica{{National Enquirer Article 2008|cite}}.

Note that this is different from Wikipedia, where all the citation info is included on the spot.  You're just using the name; the actual source info is in a separate card.  If you cite a source that does not yet exist, then you can create it later.  Some communities may want to restrict this socially, but there's no technical reason you can't cite a person, an image, another search, etc.  It also means that you'll be able to use our "inclusion" interface to enter citations.  It would be possible to build a special citation button; there's not that much to this part.

 

The cite view will be a superscript number.  Mousing over it will give a short summary of the source (needs design: how to configure?) with links to the full source page.

 

queries

 

At present it is straightforward to query all the cards referenced by a given card and restrict by standard parameters (eg, all the Source cards mentioned by a given Claim). We can't, however, search by the inclusion view.  We would need to upgrade our reference tracking (and CQL) for that to be possible.  It's also not yet possible to query cards based on order of reference, but that is not needed in this solution.

 

 

A +*citations card can be added to any card or list of cards to find their citations.  For example, if the above card were entitled "Squorigins", the collection of citations inside it would be called "Squorigins+*citations}}.  If you have X+*citations and X is a collection (Pointer or Search), then we should find all the citations referred to in the collection.

 

Note that these become standard inclusions and can use all the same patterns as normal inclusions.  

 

Tricky Parts

There are two keys ways we might implement the +*citation card, as a virtual search or as a virtual pointer.  each has its challenges.

 

+*citation as search

One big trick here is that we don't yet have a way to narrow inclusions on the basis of the view with which they are included.  You can find all the cards that A includes, but not all the ones that it includes in open or (more relevantly) "cite" view.   But to match the superscript numbers (and to have the numbers be consecutive) it's important that the results all of the cited sources and only  the cited sources.

 

The other trick is that searches don't yet have the capacity to return results in Pointer order, so see respect order of Pointer items found with referred_to_by.

 

+*citation as pointer

There are two ways we could do citations as a pointer: static(real) and dynamic(virtual).

 

In the static solution, every time you save a card with citations, it automatically generates a pointer card that stores all the citations in a pointer.  The advantage of this solution is speed.  The tricky part is configuration / implementation.  What triggers the generation of the citation?  If it's the presence of the "cite" view, then again, as in searches, there's some trickiness, as there's not really a trigger mechanism based on views.   Even harder: how would Wagn know to add the more complex citation patterns mentioned above?

 

In the dynamic solution, when you go to card1+*citation, it parses card1 on the spot and generates the citation card right then.  This is slower, but you don't need much configuration: you just do the citation lookups whenever they're requested.

 

numbering across multiple cards

Regardless of the solution for the citation list (search or pointer), it will be tricky to handle numbering citations differently for multiple cards.  For example, imagine that we were trying to grab citations from both +summary and +about and we wanted them in one list.  If we have some three sources in +summary and four sources in +about, we would need +summary to have citation [1], [2], and [3], and then +about has citation [4], [5], [6], and [7].  That means the wagn renderer would have to have more contextual information than it currently has.  when rendering one card it would need to know (a) that it was going to be part of the generation of a citation list and (b) where it fit into the current order of things.

 

One solution might be to generate the numbering in javascript so that the renderer can still be a bit dumb on this stuff, but in any case there's a whole lot of "awareness" that will need to be added somewhere in the system for this to work.

 

Next Steps

I (efm) would suggest that we start small on this.  That means that we start by implementing:

  1. as a module for wikirate.org and then generalize if there is interest. 
  2. using the "real" pointer solution, using wikirate modules to trigger their creation (meaning this will be set up in code, not via wagneering)
  3. for single cards only.  That's not to say that you can't use queries to generate meaningful lists of sources (you can); it just means you can't do citation numbering across multiple cards yet.

 

 

 

Seems like you'll end up wanting one view for the citation wherever it appears in the text, and another that is used down in citation list section. Each can then automagically link to the other, etc. The inclusion above could even begin life as something like {{*citation wanted}} (an option in our link/inclusion builder?) which shows a link that offering to add a citation, then when one is added it converts to the appropriate inclusion markup to show the super-scripted number linked to the citation list below. --John Abbe


I just updated this card with a new proposal that would reduce complexity dramatically.

 

It's based on the idea that the traditional way of managing citations (journal style footnotes or endnotes) is really based on optimizing the user experience for people *looking at paper*. The above proposal is much cleaner for web experience and involves many fewer context shifts. It would be straightforward, as mentioned, to generate a list of sources for a given chunk (or chunks) of text, but I suspect it's best to be careful not to present this in a context where it will be experienced as clutter.

--Ethan McCutchen.....2013-10-01 22:41:05 +0000

support citations+relevant user stories