On Dec 20, 1:31 am, Paul Downey <[email protected]> wrote: > Hi Jim! > > [judicious snipping follows] > > > http://tiddlywiki-cooker.jpick.user.dev.freebaseapps.com/ > > That's certainly interesting idea, nicely implemented!
Thank you! > > There are about 225 topics that make up the 'core' 2.4.1 TiddlyWiki > > recipe that I put together. > > Ah, that sounds interesting, if only from the POV of cataloging > "concepts", at least from the perspective of IA. > > > Using this core recipe, it should be possible to build additional > > recipes that add more content, plugins, etc. just by creating new > > topics and linking them together. > > How "fresh" is the content in Freebase? It's a Wikipedia-style system. Anybody can contribute content (under a CC-BY license), and also edit content. So it's up to the users. They have automated robots that are pulling in content from places like Wikipedia, but I'm not sure how they are keeping that in sync. I'm sure some of the Freebase staff could better answer how 'fresh' the data is. > I notice a lot of the tiddlers are tagged version 2.4.1, I'm guessing > you've a plan for evolution of core code / plugins / etc? There are actually two datastores underlying Freebase - a directed graph datastore, and a content datastore. I've chosen to store the stuff I consider to be 'metadata' in the directed graph datastore - eg. mostly the recipes - plus elements of the tiddlers and javascript fragments (eg. filenames). That's what you can see via the tiddlywiki.freebase.com website. With Freebase, you define Types, which can depend on other Types, and they can have attributes. Then you can create Topics, which are instances of the Types. The actual content of the tiddlers is stored in the content datastore. These are hashed based on content, so it's pretty efficient. Each Topic has it's own GUID. A complete top-level Recipe and all of it's child Topics forms a nice little connected graph. The Acre app just iterates over that, finds the template, fetches the content, and does all the substitutions (just like cook.rb does). When I import '2.4.2' or '2.5.0', I plan on creating new Topics for all of the Recipes and Ingredients, so each top-level recipe will have it's own little directed graph. The names of the topics aren't that important - it's the links between the topics that matter. So there will be multiple topics with the same name for each ingredient, but they will be linked into different graphs (plus they will have a different number for their 'version' property, which isn't really used anywhere). 'Vertical' recipes can use these 'core' recipes (or subsets of them) just by having references into their graphs. Ideally, the 'cooking' process should just look at the metadata, and ignore the content -- that would be the most efficient and clean. But since I'm trying to be compatible with the current recipes and templates, there is a lot of magic that needs to be implemented. Hopefully I can refactor all of the special case handling into the schema, and the 'cooker' implementation for each type can be extremely minimal. At this point, I only implemented enough of cook.rb to render 'core'. So currently I have support for Shadow Tiddlers, but not regular Tiddlers. Likewise, I only have support for javascript fragments, but not plugins. For Tiddlers, I plan to store the metadata (eg. tags) in the directed graph. Likewise for plugins, I won't store the *.js.meta files - I'll just add the metadata from them to the related types. > > There are hundreds of recipes that > > work with the standard cook.rb tool that could easily be ported over. > > Ah, when you say "port", how much work does that entail, and for whom? What you currently see is mostly hand-assembled. Except I had to use a Python script to upload the source code of each ingredient to Freebase. I need to automate that a bit more. Now that the schema is a bit more settled, it wouldn't be too much effort to make a tool that would read an existing recipe, and automatically generate the corresponding Topics in Freebase. They have a very friendly JSON API for that. As I mentioned above, I've only implemented a subset of cook.rb, so I need to do a bit more work to support regular Tiddlers and Plugins in order to be able to represent and output a normal 'vertical' TiddlyWiki. > I'd also point you at TiddlyWeb, which offers an alternative method > for for assembling TiddlyWikis, and which I know some folks prefer to > cook, and I've heard some offer as a replacement of cook, at some point. I've been playing with it (several months ago), and it's been an inspiration. I even demoed it in Seattle at the Google offices during an App Engine Hack-a-thon they held there. TiddlyWeb takes an existing empty.html and augments it with additional content. Currently, my app just generates an empty.html from scratch, and can't do the additional content yet. So, currently, the two apps are really covering separate ground. I can see extending TiddlyWeb to go more of what the Acre app does, and extending the Acre app to handle TiddlyWeb's concept of 'Recipes' and 'Bags'. I haven't looked at TiddlyWeb's plugin interface yet, but it should be possible to write a driver for it that could query the recipes stored in Freebase using their JSON interface, and use them directly. There is already plenty of Python Freebase code ready to use for that. As Freebase data is also exported as RDF data, an intriguing alternative might be to query the recipes via a Semantic Web SPARQL endpoint, and piece together a recipe that way. If that was implemented, then you could use any RDF datastore to store the directed graph. TiddlyWiki seems like a good way to blur the distinction between code and data on the semantic web. :-) Cheers, - Jim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
