Some things don’t have names. The drop down choice box is shown for Groundline. Now, i’d think we’d categorize that as a BindinG knot (choice BG on menu, like it’s brethren #1674 that i favour, or the Constrictor itself); but it’s popular use is as more of a Hitch (H).
i think this level is a good place to put in page nos., seeing at this level they are all together. Just get your chapter done, mark the page nos. for the first knot on each page down the column of the spreadsheet. Then, copy; then paste each value down the column until you hit the next and it is rapid fire done.
I see from the JPEG that you’ve dropped the Prime Knot column which is used to identify duplication. I’m sorry but I don’t see any point in listing the same name many times unless they are variations identified as such - any slight variation in spelling will give the impression of a different knot. When this is turned into a database it will cross refer a searchg for knot #xxx back to the original entry - if a list of all entries eg for a clove hitch is required then this can easily be provided from the name or any knot number which refers to a clove hitch. Having thought about it although page numbers can easily be included I am not convinced that they add anything useful any more than they would to a dictionary. For those who have not seen the opriginal spreadsheet and notes this may not make a lot of sense I’m afraid - if anyone would like a copy please let me know but PLEASE don’t amend the spreadsheet layout without reference to me or else this will become an impossible task - once an initial pass has been done through ABOK and some basic checking done then conversion to a data file will give access to the data so that it can be corrected, augmented and expanded. But as with any computer exercise there has to be standardisation (even if it proves to be wrong - it can always be corrected later).
I am not trying to be secretive about this nor am I a ‘control freak’ (at least not the last time I looked!). To help I have posted a copy of the blank spreadsheet onto a Wiki page so that everyone can at least see the details - but if you want a copy to complete please email me (barry@lizziemint.co.uk) so that I know who is doing what. The Wiki is www.knotindex.pbwiki.com
Ummmmmm i forgot to spread open the prime column, it is still there; and i put the page etc. stuff on the end columns, where i can easily delete or hide,
Hi everyone. Sorry I have not been able to get back to this topic until now. I have been very busy with a client and their server for the past two weeks, or so. I have some responses to a few of the above posts. Thanks for replying by the way.
How might a group of volunteers, not conversant with the technicalities of php and sql to your level, best proceed ? Or would everyone need to learn these systems?
Derek
To proceed we would need someone, or a team of someones who know the in’s and outs of PHP and MySQL and how to program in that language. Next I would like with any other client design a basic layout that would be similar to a wiki but have the feel of a blog like word press. Then on the back end, or the administration end their would be 2 or 3 ways to log into the system,
Administrator - The one who would be webmastering the website itself.
Moderator Login - The ones who will be in charge of helping keep the site and it’s contents and members in order.
Author Login - The ones who will be adding and editing their published work to the site.
The Administrator would be the only one who would have to be familiar with php, mysql and some html. That person would also be in charge of the backend of the system itself. The moderators and below would only have to have a little familiarity with some html because of the online word editor that I have in mind can be used in a what you see is what you get fashion, or by entering raw html code. The online word editor that I have in mind is much like the one you use to post here with one thing different. You can switch to a panel, or window that will allow you to enter your own html code so that you can customize your entry with more finite details and accuracy. The online word editor I have in mind is called TinyMCE and it is designed using JavaScript. It has the basic feel as the microsoft word interface does at a very basic level. Another good addition would be a way to upload a small photo or picture of the finished knot. Just an idea to think about.
Derek I hope that answers your questions.
Barry;
Am I right in thinking that SQL and PHP would, in an application like this, be used to front end a data file? If so are there any particular constraints on the file format? Excel is an easy to use tool for gathering data which can then be transferred to virtually any format (if necessary via an intermediate transfer format) such as dBase for example. I don't see a need for a relational database although Access could be used if that simplifies things.
Barry
PHP will act as the front end feed for the MySql that all will be able to view. File formats that can be converted, csv(Excel), txt(Text File)… Those are the best for conversion factors. MySql can interpret those files the quickest and with accuracy. dBase would not be a good one to use for the conversion since MySql can only interpret dBase from a command line interface only and not all of us can do that, nor do alot of us have Linux for that. If you use Access to build your data for submission it can then be converted to a csv file or even a .txt file. Which ever way is easiest for you and your entries to get done.
I hope that helps out Barry.
You must keep in mind that the Abook is very extensive with data and illustrations. There will be a very heavy use for something like this online for sure. PHP and MySql can handle that kind of use for years to come. I can put it this way, people will wear out before the website will. The two elements used are very complimentary to each other and work well in an industrialized atmosphere. I think that the database itself would only be as large as 5 to 6 megs, just a guestament though.
Most of what I have said here is very much on the I.T. level. But these are just suggestions for all of us to consider along our path to index the Abook. The object for me is to make that task easier and quicker by making suggestions as I have. I don’t mind explaining it either. I really think this is a great idea for indexing the Abook and a very solid way to accomplish this task in an efficient way for all those working on the Abook project. I believe this could also generate funds for the Guild to promote membership on a higher level than what we have now. This can offer the member a way to collaborate with other members, it can also cause great discussions among all of us knot heads. Well just some suggestions, or ideas to consider.
Thanks - that was very helpful. I have had an e-mail exchange with Mel (Webmistress) about how to structure the MySql files and I have a draft (as yet unseen by other than me as it’s not yet complete). You’re quite right - a set of relational tables will give unlimited (within reason!) room for expansion and although I have never tried this with MySql I have bult some big databases in past years using dBase and Dataease. The Excel file is to build a basic framework only (a couple of macros to clean up some issues and the data will soon be ready for the tables in MySql using CSV (which is why I asked that knot names in the sheet be separated by “-” to avoid spurious commas). I’ll sort these out at the end. My only worry is that we digress too early into a discussion about what to record (if it’s there and we don’t need it it can be reomoved in a mouse click, if it’s not there then adding data should not be too difficult) we will never finish the first pass. As an example I note that TheTreeSpyder has included the graphics used by Ashley (Anchor etc). If that is felt to be desirable then text which is meaningful would be better (eg weak) then we can continue that theme later with knots not in ABOK - but I think that if we are going down this route I would prefer to use our own terminology based on our own assessment rather than risk infringement of copyright.
But any changes to a contributor’s worksheet sheet must be done to the master copy as well so if there is information to be added to the spreadsheet ie additional columns (there is no need to remove columns until the end if at all) would forum members post here please and if there is a general consensus I will add it in (adding the data to completed Chapters can be a mini project in itself). What is the feeling about page nos? (I haven’t had chance to check yet whether they vary between editions but if they do then this may be more confusing than helpful).
As i remeber the page nos. are the same in editions i’ve seen. We wouldn’t want any infringemeant of course; and this is why i put ‘quotes’ seperate from notes, so that they could be handled differently or even discarded if need by. By including the icons, i’m trying to do the author honor, by respectably noting stuff inthe quaint way he did. i thought about placing ‘weak’ etc. in there, but figured i’d maintain the original perspective,a nd that if allthe like stuff was named alike, it could be renamed later globally, the best way i thought was to use theauthor’s own un-ambiguous terms. Though, this is a new age apporach; i wouldn’t want the output to somehow be so sterile; away from the original feel and intent.
Overall, i would hope that the project increases ABoK circulation, usaeage and reflection. There is a ton of stuff in there. but the ominous size etc. comes across less accessible like a referance book rather than a common tool. But, then too; that large size gives a hefty, real feel to the writings about power etc. when holding the large work, than viewing on a computer screen as it is.
Hi all. I have attached a file that contains a sample of the MySQL database schema dump file in .txt format. This .txt file contains the MySQL commands and instructions for each table to be created.
The overall schema is very basic. I only put this here to show you how easy it would be for Mel or anyone else that should be involved in the creation process. The sample schema was done with a program called SQLyog Enterprise Edition, I also have another program I use for fast preset builds of simple websites called PHPRunner. I used these two programs to create a simple schema layout of a database.
The relations are pretty much unlimited, but has to be established at the beginning of creation. I fear that changing how the relations work later on would be a bit labor intensive even for me.
The text file is interesting - I don’t have a Mysql GUI tool and will leave development to Mel in due course. The basic file creation is (I suppose inevitably) similar to VB, Pascal and most structured database packages I’ve seen. Although I don’t think relationships will need changing as long as we get the design right to start with, that this is difficult is something to consider. Although I can use Excel, Word or whatever to set out out the data tables and their relationships it would be useful to find a simple graphics tool designed to do this (I used to use Visio but it’s too expensive to buy personally just for that).
Another reason to mark the chapters, would be because most the chapters from the 3rd on are for a specific range of mechanic and/ or uses. Therefore they are already divided into groupings of likenesses that would give some definition and understanding to them as a whole as well as separately. Perhaps we could have our own comments to offer observations of the similarities and differences, evolutions of thought from 1 lacing to the next etc. that make up a series of like lacings -already broken into chapters for us! So, once the database was populated, it could be indexed by the name field as an index, or be indexed by number, for a mass table of contents, of the lacings; then divide at chapters. Having a blurb of words at the chapter separations, then the numbered names below that break at 3 across or whatever could be a good thing, with about no more effort.
I use a list of chapters to keep track of who is doing what (this list also shows the starting and ending knot number of each chapter) - this should be easy to incorporate into the greater scheme of things when we build the database so that you could for example list all knots in a chapter - though many will be duplicated across more than one chapter. Perhaps more important is once we have index ABOK we can move on to add the knots not there and modern usage (I strongly support Geoff Budworth’s view expressed in the latest KM - ABOK is frozen in time, knotting needs to move on).
yes I was intrigued by the idea of abok being electronically available.. at least the names and numbers and perhaps a comment section to refer to (via this site) when being referred by someone commenting eg abok 1010 w/o having to riffle through the actual book… (although i enjoy that as well)
This project has been moribund since March this year simply because volunteers have not been forthcoming. I was taken seriously ill in early May and now as Hon. Secretary I have little time to devote to the project though I still have the files etc. In short the idea was to use Excel to record a list of all knots in Ashley but identifying duplicates as far as possible and recognising that we would make a number of mistakes which would need correction. The only exclusion was for knotted article designs which are built from other knots not least because they cannot easily be named and identified. Although I cannot do the idata input I will continue to act as ringmaster for those who wish to do some work - I allocate a chapter in Ashley and send a blank spreadsheet to the volunteer and when complete I check it (only a cursory check to make sure that the principles have been followed) and then add that data to the master. Once the Excel list is complete we can move on to checking editing etc before publishing the list using a database (Excel was only ever intended as a data capture tool as it is in common use).
I will need a few days to refresh my failing memory and dust off the files but if there are volunteers out there please let me know (secretary@igkt.net) and I’ll get in touch with you personally. Incidentally I haven’t put the blank spreadsheet on the web so that I can keep track of who is doing what and avoid duplication.
One last thing although Excel 2007 is the software of choice I have in the past taken data in Excel 2003 and MS Works and could use a Word table or even a simple csv file created in Windows Notepad so don’t be put off by the need to have Excel.
I understand that this specific project is confined to ABOK. But I would like to voice a humble opinion.
Even though the great book is the most comprehensive work to date, why stop there? How about a database in which all the knots of ABOK is presented, and then as many knots that are not? In such a database, additional information could be added, as names in other languages, suitability in various materials and so forth.
To be honest, the book is lacking in post Ashley materials. And actually, some knots have been discovered/invented since. Who knows, maybe another one will se the light of day.
Regarding databases, excel and volunteers, Wiki springs to mind. As a package, The fileformat involved would be at the backend (no need to muck about with proprietary fileformats), and volunteers can do a little bit of work whenever suitable. Most importantly, no one person need, or should, pull all the weight. That is harmful to the project when he gets tired or fall off the web so to speak.
Through a web interface no one need to be excluded who would want to give a hand. To me it would be valuable to be able to make searches on materials used, conditions for use, name (in various languages), ABOK number, tied in bight or at end. Well the list could be made long. But I believe a wiki could fit the bill.
To make the information even more accessible to people outside the knotting community, the knots could be presented at the already established Wikipedia and then do the indexing there as well … Some knots are already up.
This project started by looking at Ashley but with the intention of moving on once that was complete and checked. A project like this needs someone to hold the reins and ensure that we are all working to the same brief (I have neither the time nor the inclination to “do all the work”) - if not then we will get nowhere. There has to be a logical sequence and although the approach I advocate may be idiosyncratic and not to everyone’s taste without some organisation the project will be chaotic. The file format is important only to the extent that everybody captures the same raw data using the same analysis - once all the data is available electronically the analysis, search options etc can be set to suit almost anything but the main grind is accurate data capture. Excel is used because it requires no programming expertise and is widely available. It is by no means the only software that can be used to capture the data. Ashley is organised into chapters and when someone volunteers I allocate a chapter to them to complete in their own time - this avoids duplication. So far though I have allocated several chapters and nothing has been done by the people who volunteered so this work is still available. I don’t see that a Wiki page would offer any advantages until perhaps the data needs to be examined when we can use our own website anyway.
We move into the 21st century at last! With assistance from Andy Spencer we have a database for data capture on this website. However I am awaiting a reply from Faber & Faber (the UK publishers) about copyright so the database cannot (easily) be found without the URL. I do not want this published but anyone who wishes to help with this data collection should drop me an email or personal message please and I’ll send you a link. If this ends up being published by default then I’m afraid that we will have to put password control in place until we are clear that we are not infringing copyright.
The grouping of knots in the drop down menus was mine - please stick with it for now and let’s try and get a substantial amount of data input, then we can look at the finer points about editing, presentation etc.
here’s a thought. how about google docs? you can selectively enable people for sharing. requiring people to have google accounts should be no more onerous than requiring them to have access to particular editions of excel. if you want to switch, you can always save it out as comma delimited for transfer. then the work will always be in the cloud for all participants to see.