I can appreciate that a lot of work has gone into this but if the object is to index Ashley completely then forward references should fall out as knots are added. For example there is no need to say which knots are started with a RT as this would be referenced when these knots are indexed - to arrive at the list above one would simply search this field. Again I strongly recommend designing the method of storing and retrieving this data before going any further. Happy to help.
Barry
Barry,
that sounds like a very good idea, but I have no idea how to do it nor the time to learn. Will you do this? I will give you all the information I have to facilitate this.
Cheers, Peter
Hi Peter
I suggest we collaborate - there is not much to learn to get the data recorded - but do you have a copy of MS Excel? Iāll happily design a sheet to get going and perhaps we can agree (with others joining in if they wish) how best to divide the work. Once we are well underway I suggest asking for comments on the methodology as once weāve got that about right not only can the job proceed apace but verifying and editing can also get under way. Incidentally Excel is not essential - a word processor would do and the final form of the index can be agreed once the basic work is nearing completion (I have in mind that this lends itself to a computer solution not a printed one). To start with Iāll put some knots into a s/sheet to demonstrate and test - this I can email to you and post a text/pdf version but the latter would have limited search capability.
Barry
If you do not have MS Excel, could I suggest that you work with OpenOffice which works with the same files but is totally free. I use it for all my spreadsheet and word processor work and it can export/import in MS format if you want.
As for a database, we are probably not too far away from the Guild waking up fully to the importance of the Internet, and with this realisation will come the opportunity of having Guild based databases served by SQL and PHP so that Guild users can carry out searches through the Guild website. This has the advantage that each user does not have to carry an up-to-date copy of the database on their computer and they would always be accessing the most uptodate version whenever they did a search through the website.
If you are thinking of this sort of usability, then perhaps inviting Mel to help with the setup might help in the future.
Derek
http://openoffice.org-2009.com/index.asp?aff=101&camp=gg_oo_uk&se=google
Derek
I agree - to start with Iād like to try out a simple flat file in Excel to get a better idea of how to record the basic info.
Mel
Any help appreciated, please.
Barry
That wont be too hard to do. As you can most likely tell this Forum board is built on php with mysql on the backside holding the data stored from all the posts. My website is based on php and mysqlā¦ If you were to build this project using both of these fabulous web programming languages, you would be able to build the web data base program in a fair amount of time and then populate the data base much quicker.
While building the initial data base in a flat file would give you a better idea on how to build the data base structure in mysql, I would not recommend using a flat file for the sole purpose of the data base itself. Excel will not handle that much data being served up on a server that will most likely have a very large scale amount of users accessing it continually 24/7. The load on the server would be greatly diminished. When the server starts to experience a heavy load, then the operations within the server will slow down producing a very slow response time across the DNS. As you will be able to tell with building the flat file data base, that after it starts to get full, even on its own it will take some time to start up just by itself.
Using php and mysql is the way to go for such a task as you all speak of. I love programming with both of them when it comes to building websites and ecommerce solutions. Both solutions can be secured using the HTTPS for secure logins and for secure site roaming and administrations. Any data that sits behind the HTTPS is encrypted at the 64 bit level as a start. Say you open a little ecommerce end, or you are just surfing the site and the many different pages, all that is encrypted. Every piece of data that is sent out from behind the HTTPS stays encrypted until it reaches for example your credit card processing company that then has a key on their side to decrypt the data sent to them. Just another really great feature of php and mysql working together as a team.
Well just my 2 pennies worth as from my own experience. If you were to build this application, php and mysql is the way to go. I have been using both for years now and stand behind it 100%ā¦
Brianā¦
Hi Barry, Derek, Brian and others,
Yes I do have Excel, so no problem there, Also have Access which I believe is a database app although it looks like a fancy version of Excel to me? Would that be any better to use for a pilot?
Good to see a general level of agreement on the way to go forward, lets go for it!
Cheers, Peter H
Brian,
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
Brian
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
This is a call for volunteers to help with the Index project. I have developed an Excel spreadsheet to record basic details about all of the knots in ABOK (with the possible exception of some of the designs using multiple knots) but including every number, knot or not and simply showing fastenings which are not knots (in a minute Iām going to get the k and the n the wrong way round!) as just that. The sheet uses a variety of codes to save typing - these can be replaced in the final version with text. To convert to MySql should be straightforward but Excel provides a good editing tool for now. Notes are included on a separate sheet and comments are there to help. No experience of Excel beyond being able to type in columns is needed (and if you donāt have Excel then another program such as Open Office is just as good.
I will co-ordinate who is doing what using a control sheet and once we have finished a substantial chunk I will ask Mel to put the sheet on the website for downloading, commentary (always welcome anyway) and error correction. More about that later. I think that up to 6 volunteers initially and letās see how we get on (more than that once I have made sure I can cope). Rather than post on the forum please email me (barry@lizziemint.co.uk) and Iāll send you a blank sheet for completion. Please let me know whch Chapter you would like to undertake (I suggest sticking to one at first) - Chapters 3 and 4 I have done already and Chapters 1 and 2 I would leave until last as the knots there are a repeat of knots covered in later chapters (the sheet cross refers to the prime number for a duplicate knot rather than record the detail twice or more - the prime number is the one in the Chapter dealing with that type of knot eg Bends).
So first come first served drop me an email with the Chapter you would like to do and Iāll take it from there.
Barry
No volunteers so far - has everybody lost interest?
If the initial data is gathered using Excel, I can upload it into a MySQL table using something called a cvs import to get you going. Once the initial data has been assembled, it can also be examined with a view to the best way to store it in MySQL. I appreciate that a flat file might, at first, seem to be the best way to proceed. And itās certainly the simplest approach. However, if this is truly intended to be a long term project with the capacity to handle a whole range of searches and queries, then a series of relational tables right from the start might be the best way to future proof the whole thing.
(For the less technically-minded, relational tables are simply a way of storing, for example, the ABOK reference name of a particular knot in one place, the information on its construction in another, itās potential uses in a 3rd table etc etc. Splitting the data up in this fashion greatly reduces the amount of work that the server needs to do to provide answers over a whole range of questions)
Once the data was imported into MySQL, attention would need to switch away from Excel and over to the central online system for all additions and amendments. Initially I could either write, or source, a basic front end system for all of the data management - ideally accessed by authorised individuals only using a username/password combination. Longer term, a more sophisticated admin interface could be gradually added. If this was tackled on a modular basis, it would limit any additional expenditure from the Guildās point of view and go some way to ensuring that the right tools were being built in the most appropriate way.
As soon as the data is online, work could also begin to allow users to run searches etc - either on the public site or within a restricted area.
Someone mentioned using Access. Frankly, if the intent is to get this online asap, I wouldnāt bother. Access isnāt well suited for online storage or usage - especially on the igkt.net server. Stick with Excel.
Ultimately, a full centralised, dynamic, online system is highly feasible. However, until I see some sample data, I canāt really advise as to how it should eventually be organised other than to echo Knot Headās suggestions that a combination of PHP and MySql would be the way to go.
Many thanks for the reply Mel. So far I have only one volunteer (Squarerigger who is looking at Chapter 40 - probably the biggest job of all so Iām grateful) but Iāve completed 4 chapters so this should give you an idea of the data being recorded. Iāll email you a copy of the spreadsheet to have a look at for now - if itās worthwhile splitting this into related tables then I should be able to easily do this in Excel for uploading - at first glance this might be a starter where a knot has several names or is duplicated - canāt think of any other one-to-many relationships but Iāll think about it. If anyone is interested in looking at the data rather than doing any recording let me know.
Barry
Itās been suggested that the latter part of this thread might be better placed in the Computing board to allow technical discussion centring around IT to continue without causing aggravation to other posters.
Does anyone object?
Are there any suggestions for a suitable āsplit pointā where the discussion becomes more IT than knots?
Mel
I suggest from reply #46 onward - I think that was when I started the techie discussion.
An update. Chapters 3,4,5,20,21,22,26 and 40 are now either complete or being completed. Leaving Chapters 1 and 2 until last (as they largely repeat later knots) does anyone else wish to join the 4 of us currently working on this?
Barry
i think that we could / should include page nos., and that the person doing a chapter should also include chaptNo. and chaptName; or they should be added by ācollectorā in bulk as 1 spreadsheet would contain before joining to the rest of the heard. Then, when broken up into sorting on any of the columns in spread sheet(sort by name, use, page, chapter etc. it would be sorted, searchable by chap etc. This would also give more friendly info base, introduction to the lacing (by descriptive chap name), and perhaps help verify if that was what reader was searching for. Perhaps should be more than 1 altNames field, so that if more than 1 name, could alphabetically sort to both, or dbl. entry just for same (copy above row verbatim, except for the different altName.
You can export from excel with varied delimiters (in addition to space) such as .csv (comma separated values), txt(tab delimiter) etc. But, there are also more powerful free converters. Also, xml might be the way to go at some point?
Should allow, make space, implemeant, other reference picture links or info links. After assembling all of this, getting it to mysql etc.; you are 1 step away from making a static form, to fill with the dynamic data from mysql, and putting a picture on it for anyone coming to this site. Having most of the pix links to this site eventually would look good, and further set this place as the recognized authority. Being recognized so, could increase site in terms of itās size and readership as well as members of site, igkt etc. Also, cross referancing to other books would be good in future. If someone was looking at book to buy, site to go to, they could search target knots and see what book or site has most of type of lacings they seek. So, not to increase the workload, but if someone is doing a chapter that they have chosen by familiarity or fascination, and it is no workload added, jsut work saved later, perhaps they could be included. In some of the working knots there are safety and usage icons that might also be faithfully noted, and/or extend those icons to more knots, or choose separate of same on broader base, to indicate safety and usage. The more meaningful stuff sifted out on a pass thru, the better the potential of the final form. So, perhaps a larger āskeletonā to hang stuff on, but optional to fill. Just do what you have the most powerful assets towards on the optional stuff, too much trouble save for another pass(er). Hopefully once enough is showable and running, more will add in what is easy for themā¦
We might seek out others, that might have come and gone; because this is the stuff that hasnāt been here, but should have been. i have a few people in mind to bounce the idea off of, but think everyone hear should have ā1st shotā etc. It seems like at this step of the evolution, bored members that might not read here - browser just shortcuts right to āFancy and Decorative Knotworkā forum, never sees rest etc.
I am with you on this and perhaps it would be helpful if I set out where we are and where I see this project going. First off I have a control sheet which shows a lsit of the chapters in ABOK (number and title), the knot numbers in each chapter and who is analysing which. At the first pass I would hope that as well as knot names and some other simple data we can also note those entries which are not knots (eg cleats, fastenings) and the primary entry for each knot (eg the bowline at 1010) so that duplicates refer back to a primary entry - it will be interesting to see how many actual knots there are. Perhaps we should note knot designs as such ie a piece made from a number of knots such as a wall hanging. Page numbers are not in the spreadsheet at present but I donāt mind adding those at the end in one pass. The aim at this stage is to create a list of all 3855 or so knot entries with basic data about each.
This will then be made available for initial checking and validation then exported into MySql tables to allow for expansion eg the names of a knot will be in a related table so that additions will be simplified as will searching. This gives us a good jumping off point to add,enhance and correct data whilst also providing a repository for knots not in ABOK (though many may predate ABOK in publication), perhaps with numbers starting at 4000. I am all for adding links to pictures, videos etc whether on the IGKT site or elsewhere but this is a later phase.
I should add that other than informally Council are not aware of this project - they will have to approve any expenditure in due course such as adding to the website. But I think it will give the project some real clout if we can show that a first pass through ABOK has been completed and this is not just pie in the sky.
Finally thanks TheTreeSpyder for your helpful post and for volunteering to join the merry band.
Barry
Iām having trouble visualizing both what you are doing and how you are doing it, thus making it very difficult to help.
I take it the four of you actively working on the project are sharing an excel spreadsheet back and forth?
Would it work to post your column headings and a line or 2 of data just to give us an impression of what youāre after?
Wonāt different editions cause troubles with page number references?
I donāt know if it helps in any way, but I just went through ABoK looking for mystic knot mentions (http://www.knottynotions.com/mystic/nomenclature-ashley) is this the kind of thing you are looking for? Sort of? 8)
When someone volunteers I send them a spreadsheet (without data but with headings and notes) to complete for a chapter or chapters. When this is returned the knot numbers will be in one or 2 blocks so I copy these to the master sheet which has all 3855 knot numbers in it (and by now some data). I donāt know to what extent page numbers vary between editions - something I will check though before spending energy on a waste of time. If you have an email address listed (should have looked shouldnāt I?) Iāll send you a blank sheet with a few entries copied back from the master for illustration. If you want to have a go please do - just let me know which chapter you are doing to avoid duplication or if you want to just have a look at it feel free. In answer to your last question - pretty much yes.
Barry