I wrote to the publishers some time ago but as they do say it will take at least 4 months to respond to an email I am not holding my breath. The Council use Google docs for sharing information but it seems to be clumsy for collaboration rather than just sharing. I am happy to pass the link to the area of our website on the same basis that I would have to allow access to Google.
Barry
Hello everyone. Sorry it has been a while since my last communication. I have been busy with the job as of late and working on my own projects for my website. With that in mind, I will convey that this project I am still working on but mostly complete building and it is functional and working at 98%… I have on KHWW as most of you know, The Grid Maker made by Tim Alwine & Son. In a forum discussion we had recently, we talked of a Grid Maker Catalog of a sort. Well, I thought at first this is going to be a box of worms waiting to roll out and dump on the ground for me. But out of plain curiosity I built one with a wiki type concept and approach. This project is very custom and more suited for the knot tier and leather braider to upload and catalog their grids they make with the Grid Maker.
I will have the Grid Catalog out this Friday for use by my website members to try out and see if they like how it works or not. I will post here to let you all know how it worked out for week or two. On Friday, if any of you are members of KHWW the Grid Catalog will be open to try out. You will be able to gain access to it from the Navigation Menu after you login to KHWW.
In the mean time, if this application works and serves the need of my site, I was thinking of building a similar application for the Abook Index. Now I can add another login page to it so that only the ones that are assigned to the work can gain access to the Abook Index. I believe I will leave this decision to the other members here that are committed to this kind of project on whether I should proceed with building the database and then the pages to fit the database structure.
Brian
I am so sorry for having to ask this. But I have totally forgotten as to the reason why we are wanting to index the Abook. Could someone help remind me?
Brian…
I thought it had something to do with putting names to the numbers and getting a proper count of the knots actually in the book, but maybe that’s just what I want an index of ABoK for.
Thanks Carol. I appreciate the respond.
Brian…
I’m aware I’m bumping a 15-year old thread here, but just a little note to say that I support the idea of cataloguing ABoK and I think the new forum can really be of help here.
All we need to do is create one topic per ABoK knot. Each one can use #tags to help categorise and classify it, making the knots more discoverable.
The preceding work in Excel can probably be ingested automagically into this forum if I can have access.
The new forum is not PHP based. Which is a good thing. It’s built with Ruby and Javascript and it’s a lot more capable and solid than the old SMF2 forum, which was seriously infirm when I did the migration.
I vaguely recall some discussion of an “indexing” project, but find nothing from me re that in this thread. As a user of ABoK, I’ve continually been annoyed that the Index has page #s vice item/prg. #s :: for a book that is largely a series of #'d paragraphs, giving a pg.# suffers from not only being needlessly inexact but potentially incomplete (i.e., if some index’d term occurs on more that one #'d prg on the page, a reader reaching one occurrence will not know to look for others).
MY indexing project thus was to convert all pg.#s to prg./entity #s (with maybe some exceptions as needed where “pg.<#>” could be given so to point out that THIS one is for a page (such things might occur in the front pages).
And … to get more helpful in the citations :: group them by relevance, this grouping maybe shown w/font difference or punctuation-separator. Some places where “clove hitch” occurs though indeed having that index’d term might have virtually no significance to the knot.
IMO, such a work is done as text, not spreadsheet. ABoK’s Index
is 70 lines deep for 12pp (nearly full) = 840 lines --a number likely
to grow with new indexing finding more. (E.g., I’ve found a further
4 occurrences of “clove hitch” to the already large Index’s number.
(Fortunately, most items have but a couple/few occurrences!))
OW, no : I don’t want nearly 2_000 topics to bother with!
I’m thinking of a maybe 15-40pp printing I can stuff in
the back of my ABoK; or which resides e-wise to be
Search’d. (Alas, my unaided eyes don’t so well see
ABoK’s Index’s fine print. )
And “each knot” in my scheme has rather
simple information --not a Topic’s worth.
I agree making thousands of topics is a large task. We could definitely start with an index. Placing any text in this forum makes it immediately searchable.
So one way to do this index would simply create a New Topic called ABOK INDEX and then add a list of data to it.
I can help with any technical aspects of managing a large volume of data using text editing tools like VSCode and other similar. For example, any existing CSV/Excel file does not need to be re-done, I can convert it into some suitable table or list for Discourse.
Discourse supports Markdown tables, so for example:
| Knot name | ABoK number | Page |
|---|---|---|
| Sheet Bend, Weaver’s Knot | 1, 2, | 9 |
| To twist a pipe, spar or post | 2025 | 329 |
Or we could keep it even simpler and just list the text without a table.
For additional benefit to knotters, we could add a column with a link to the relevant knot or page in the Archive.org free online version of ABoK (the only bit in the page URL which changes is the ‘n327’ part (ie. page number - 2), so if we have the ABoK page we can automatically make working links, considerably reducing the work.