Country Blues > Weeniepedia

Mother of all tables

<< < (3/4) > >>

CF:
I definitely understand the desire to reign in all that info out there & have it at your finger tips. My 'Master Table' wet dream is a song family tree that would incorporate just about everything relevant. I say go for it Rivers . . . although it may be a lonely venture. But what a resource! 

Bunker Hill:
It?s long been my intention to reign in all the books/articles/reviews mentioned and attempt to add to the rather overlooked ?weeniemedia? section of Wiki which somebody has valiantly started. Unfortunately the road to hell is paved with good intentions and my lack of progress being the classic example of it.
 

Rivers:
Cheap, exactly. You could get it going fairly simply, and also phase-in features down the track, good planning and database design being the key.

BH, a good requirement would be for a system able to pull disparate, rich content together I think. The Tags on the forum fit articles that cover a lot of subjects, they would be perfect if they were just a bit more targeted, i.e. were at the post level rather than the whole topic.

In the meantime if you were to start dropping articles into the wiki we'd all much appreciate it! You can use wiki 'category' tags to link to artists, regions, publications, etc. If they don't exist we can easily create a category for them. I'd suggest, when you're ready, you kick off a new topic on this board and we can figure out the structure, details and generally assist. It's a lot of fun when you get past the learning curve. And really it's not like it has to be done tomorrow. A wise person once told me "If you want to eat an elephant, have an elephant sandwich every day for a year or two".

Other thoughts: We're kind of locked into the dual SMF <-> wiki presentation framework at present which is not a bad thing. But I'm wondering if there's some way we could make new developments reasonably platform-independent so if we ever wanted to move to 'the next big thing' we could migrate everything easily. A database would be great in this respect since it's independent and could be reused in any other content management system. Also on that note, clearly we would benefit from understanding the underlying wiki database better, we haven't had any reason to study it in detail yet, it just does its thing and does it pretty flawlessly so far as I can see.

I think it would be wise to keep in mind that technology changes really fast though, much as we all have come to like the current setup.

arlotone:

--- Quote from: Rivers on March 09, 2009, 07:40:30 PM ---Arlotone, thanks for your kind offer of asistance, I'd certainly like to talk to you about leveraging database, but integrated within a mediawiki framework.... Key word is 'integrated', I think.... Trick would be to make it really easy to query and present result sets on (a framework) page without having to have pro-level IT skills.
--- End quote ---

No, I haven't worked with the mediawiki software, but I'm wondering what level of integration you're talking about. Wrapping the page template around it so it's a seamless part of the site? I've done that kind of thing before. Exposing the database data to the wiki search form? That could probably be done without too much difficulty. What else?

In any case, what I'm picturing certainly wouldn't take any special skills to use. But I'm imagining more of a lookup tool (what tuning does this song use?) than an analysis tool (what were the most common tunings in Mississippi in the late 1920's?).

I'll PM you login information for my songbook index so you can get a better sense of where I'm coming from.

Rivers:
Thanks Arlo, nice clean lookup on OTSFM. I see the BB is vBulletin and the index is on WordPress.

>> I'm imagining more of a lookup tool (what tuning does this song use?) than an analysis tool (what were the most common tunings in Mississippi in the late 1920's?)

Not sure why why you'd want to limit yourself to just a tuning column. If the database design contained other attributes they would enable additional sortable / selectable views, in various combinations with each other. I'm envisaging a fully relational database ultimately, with primary keys, foreign keys and relational constraints, repeating groups normalized out to child tables, join views, all the core database bells and whistles.

Designing and creating the database is the easy part. Initially loading it, maintaining it, and providing intuitive and functional access to it are the big challenges. A picture is worth a thousand words, I'll draw up a draft entity relationship diagram of what I'm proposing.

Navigation

[0] Message Index

[#] Next page

[*] Previous page