-
Notifications
You must be signed in to change notification settings - Fork 97
How to handle unique resources, e.g. phd thesis #3
Comments
In the convolutional_nets node, I have an entry for the original LeCun paper, which lists the title, author, and so on. Right now, it gets ignored, because it lists source: paper and there's currently no entry for "paper" in the database. Here's what I'm roughly envisioning: currently, we have a field in resources.txt called "resource_type." For each resource type, we would have associated templates which determine how it's rendered in HTML or plaintext. We would then have a dummy entry in resources.txt which is something like: key: paper which just says to look for the template for "paper." The templates would be stored in the content repository. Any thoughts on this proposal? |
Templates sound like a good idea, but logically, these should probably be stored with the frontend content (since they'll be html templates that are independent of the content, itself). One concern with this overall approach, though, is that we could have the same paper/thesis/resource repeated in a number of nodes, all with source: paper But then if paper.com changes to paper.edu we would have to update each node instead of just updating global resources.txt. Also we would have to specify the "free" tag in the node/resources.txt file (not all papers are freely available, especially in non-CS fields). Here's an alternative idea: key: lecunpaper and the convolutional_nets/resources.txt would have entry source: lecunpaper This way each nodes/resources entry is a pointer to the global resource that contains information that can be used by multiple nodes (title of resource, URL, free-tag, etc) without repeating this information for each node entry. [FYI: I just described a simple text-based relational database] This could be automated in a web form, where a new global resource is created if no previous resource matched the location tag, which should be a unique identifier for resources. We could also suggest that the resource already exists if the title matched a previously entered title. Additional note: Manually entering the resources into the resources.txt file may work for the moment, but this will quickly become unmanageable, e.g. scanning through hundreds (thousands?) of resources to make sure I'm not repeating a certain book or thesis entry. Searching for the correct source key when I want to use a resource (did I call it lecunpaper or lecun_paper) or trying to find an old entry of mine in order to make updates. Sure, after entering a resource I'll probably remember where/how I entered it for a few weeks, but I'd like a good system for finding the same entry next year, or for finding an entry that someone else made. Hmm, I can't seem to shake the feeling that a flat file database will be very difficult to maintain -- I'll open a new discussion for this, though. |
I know it feels like templates should generally be part of the view, but I'd still argue for keeping them with the content for purposes of modularity. In particular:
As far as whether to add individual papers to the global resources.txt, it's really a matter of how unique they are. My guess is that most papers will correspond only to a single concept in the graph, so it would be easier to keep all the information in the individual content nodes. But then, there are a number of review papers (e.g. the Wainwright & Jordan tutorial) which cover a lot of topics, so it would be worth giving them their own entry in the global resources.txt. To make it easier to edit the text files, another option would be just to write tools that help with that. This would preserve the benefits of flat files, especially the ability to collaborate through Github. The tools could take the form of standalone programs for editing the text which provide autocomplete. Or it might take the form of emacs/vim plugins. |
True, currently the code depends on the content but not vice-versa, so a content developer can work without understanding the code but a coder has to understand the content. But the templates will probably also incorporate CSS/javascript. Should we place template specific CSS/javascript with the content as well or make a list of valid CSS/javascript that can be used in a template? What about general CSS/javascript that's used throughout the display? I agree with your other points.
Yes, but I think we should also aim for consistency, e.g. the resource links and free-tag should always be in the global resources.txt file.
Any reason to develop standalone programs or vim/emacs plugins instead of incorporating these features into the browser? |
On Sun, Apr 14, 2013 at 11:12 AM, Colorado Reed notifications@github.comwrote:
|
I guess that depends where/how you want to use the template. The current resources display for the knowledge map uses quite a bit of css and a little bit of javascript in the [additional info] link. But feel free to rewrite this so that it ionly uses basic html tags.
Sounds good to me
I don't think using the browser is "reinventing the wheel." Data entry via a browser is not a new concept, and there's lots of highly developed libraries, e.g. jquery, that provide a host of robust features that we could use to craft nice IDE. But yes, my favorite text editor is more comfortable than a browser, and it would be nice to improve it for editing kmaps. That being said, the bottleneck for agfk will be getting users to contribute content. Telling someone to clone our content git repository, create and edit six text files for each node, then send us a pull request with the content is a pretty big overhead (and adding in that they should use our emacs plugin doesn't help much in this regard). And quite frankly, I doubt more than a handful of individuals in CS fields would contribute. So I feel we should spend a lot of time developing the browser interface to the content. This way, users can simply click a button ("add node"), fill in the data have it immediately available. We can even incorporate realtime visualization of the graph they're creating. The point is that we want to entice users into contributing, not make them jump through hoops. |
It's not a matter of browser vs. text editor, and it could be that Assuming we go with the two-tiered system, it's already possible for people Now, if people in other fields get excited about this and are willing to On Sun, Apr 14, 2013 at 12:33 PM, Colorado Reed notifications@github.comwrote:
|
I agree that we shouldn't focus on allowing complex changes through the web interface at this time. On Apr 14, 2013, at 8:04 PM, Roger Grosse wrote:
|
I think we both agree that we eventually want all the content editing to be In terms of your example, editing resources.txt requires pressing ctl-S to On Wed, Apr 17, 2013 at 8:33 AM, Colorado Reed notifications@github.comwrote:
|
Yes, you're right. I realize we're nowhere near orienting kmaps towards "mass appeal" and we probably shouldn't focus too much on mass usability at this time; it's premature. We can reevaluate this issue as agfk evolves. I would certainly like to eventually do some iterative "focus group" type studies to build the content editing frontend. |
How should we handle unique resources? Currently, we store general resources in the resources.txt file and reference them via the source tag in the node content. This prevents rewriting the same resource for each node, e.g. Bishop's PRML. But what if we want to cite a specific web page or publication. Should we add the web page to resources.txt and reference it via the source tag?
The text was updated successfully, but these errors were encountered: