Improvement of the ODB

[Alexandre]

hello,
I think that the ODB is a great great concept.
But I am worried by the usability/design of the ODB.
I think that this idea must be far more developed.

I may have some spare time during june/july/august, and I may be able to rewrite the ODB, but using the current data of the ODB (32000 models!).

I may be able to rewrite it in around 100 hours of coding I think, using the framework Ruby on Rails : to redesign the database (i mean the MySQL database, behind), to code the web interface (with all the features of the current ODB, plus other great features), and to migrate the data from the current ODB to the new one.

I could improve a lot the easiness of utilisation of the ODB, but I would avoid for the moment the web links to origami websites, and referencing only the books. The current administrators of the ODB (dennis/saj/gilad/paula) would stay as administrators and be able to change what they want. If I do this, it would be just make to help the community, not for any personal interest.

I would be interested to know the point of view of the owners of the current ODB, and to know if some people from the origami community got some Ruby on Rails or CSS skills (i'm not that good with CSS).

Thanks you!

[saj]

Hi Alex,

The ODB ishosted on a Windows server and thus utilises ASP with a MS Access database. This is why I leave all the coding to Dennis; I haven't a clue how to program in ASP!

Might be worthwhile contacting Dennis with any ideas

Saj

[denori]

Hi there,

Sounds good! I'll email Alex privately with some ideas!

Nice to see you both at Leicester. I had a lot of fun.

Dennis

P.S. Nice set of pics Saj! but the guinea pig is Max Hulme's model, not Martin Wall (Martin wasn't at the convention)

[Daydreamer]

but I would avoid for the moment the web links to origami websites

I think that the addition of links to the Database was a very important feature and it would be a pity to remove it again....

Also I don't really see any problems with the database as it is now, maybe you could explain a bit more

[Aurèle]

ODB is a very great work and tool, but, I think too, there are a lot of improvment which may be appliyed. For instances:
- ODB distincts models only by names, so I you search a butterfly made by Yoshizawa, you get a lot of aswers, but you can't know if the diagram which may be found in one book is the same as an other. It is a very annoying problem.
- ODB books could be alphabeticaly sorted by the first substantive of the title, so A Beginner's Guide to Origami should be sorted at 'Beginner's Guide to Origami (A)'
- ODB searching engine may allow wildcards
- It lacks a 'language' field in order to know the language of the book you found
- There are conflict beetwen results : If you search 'Yoshizawa' in 'author' field, you get (only!) 878 results. When you search in 'Browse Creators/Gallery', you get 9 models...
- There are some inconsistency in search engine: you have fields named 'book' and 'isbn', and you cas search for it in 'full database', 'book','magazin', 'web' etc.

I thnik ODB is a evolutive work which is construct with successiv strates, so when growing, the system is a little scrubby. Perhaps an ODB2-project, with a complex DB scheme and a rigourous gui should be an improvment.
But, I don't know ASP, I haven't work with access for a long time, so I can imagine how ODB is coonstruct at this time and how, with this two technologies (I know better PHP, XML, SQL etc.), a rework could be done.

After that, I thank you, Dennis, for your very useful work !
A/

[Daydreamer]

- ODB distincts models only by names, so I you search a butterfly made by Yoshizawa, you get a lot of aswers, but you can't know if the diagram which may be found in one book is the same as an other. It is a very annoying problem.

I think we won't get rid of this problem unless we get photos for each and every model in the database. You can't invent names for models which are named the same by their author....

[Aurèle]

Not sure...
1/ DB records of different bibliographic sources of a model should have a common field which point to a primary key defined by the DB record of the model reference. it's a DB conception problem.
2/ In theory there are differences beetwen the original name of a model (name by the author) and a name written in a book : two names (translated, truncated title) may pointed to the same model, and one model may have multiple names: the only good identification keys are a author's classification as Opus number as Lang uses, or folding method or pocess (or crease pattern) Photographic support, or datation (eg. butterfly [1988]), are good precisions.

But, I admiss, it is very difficult to maintain, as a user can add a model whithout knowing if the same model is already record with an other name.

[Alexandre]

Aurèle you talk about an interesting point, I think that I will use as model name "Rose" for the Kawazaki rose, "Ancient dragon" for Kamiya's dragon, and "Elephant" for Kawahata's elephant for example. There will be only one name per model. And yes there will be several "rose", it is normal.
And I will use the concept of "tags" to help to find the models, for example jungle,traditional,mythic,tesselation etc, one or several tags will be assignated for each model, and it will be possible to create new tags if needed.
Each unique model will got a difficulty easy/intermediate/complex and will be linked to a unique author, and linked to one or several books.

I hope that I will have enough time to do it... In the worst case I will just need a few months.

[Daydreamer]

"Rose" for the Kawazaki rose

Well, there is more than one kind of Kawasaki rose....

Each unique model (...) will be linked to a unique author, and linked to one or several books.

The problem with this concept is that it won't work if the database should continue to be an open database. If anyone adds a book with models in it he would have to have all the books by that author so that he can actually know if exactly the same model appeared in another book as well, or if this other model which might have the same name is different....

A different thing: something that would be important for me to be added for the models is which format (square, pentagon, 2.5x13.1232 rectangle, etc.) it is based on.

[Alexandre]

Well, there is more than one kind of Kawasaki rose....

Yes you are right, so I may use "angled rose" or "rose v2" or "original rose". In all cases there are no so much models with the same author and name. For example "Ancient Dragon"/"Ancient Dragon type2" and "Wasp 2.0"/"Wasp 2.6" for Kamiya. It won't be the worst issue I think.

The problem with this concept is that it won't work if the database should continue to be an open database. If anyone adds a book with models in it he would have to have all the books by that author so that he can actually know if exactly the same model appeared in another book as well, or if this other model which might have the same name is different....

Better ideas ? In all cases if we encounter this little problem, it would be possible to correct an entry if somebody detect 2 exact same models.

A different thing: something that would be important for me to be added for the models is which format (square, pentagon, 2.5x13.1232 rectangle, etc.) it is based on.

Good point. It will be included. The page in book too. But I think that I will drop the cuts/glue/number of pieces characteristics, that are currently in the ODB.

Thanks you for your comment !

[Daydreamer]

Better ideas ? In all cases if we encounter this little problem, it would be possible to correct an entry if somebody detect 2 exact same models.

Well, I know that this solution would be the optimal and cleanest one. I only wanted to point out that there is always a gap (sometimes a rather big one) between optimal and realistic. The more optimal you want to make the system the bigger the administrative overhead for the moderators of the database will be. You should keep that in mind in the design of the system.
In my opinion the same models wouldn't need to linked internally as long as there is a picture to go along with it. Of course taking and adding pictures for all the models is a huge effort as well but is a task that can be better distributed than the task of finding same models in different books, especially if you don't own them yourself. Also someone would have to go through the 31000+ models in the database to find these correlations.

Note: This all is not meant to say that you can't do it that way, I'm only trying to assist in mentioning points you might not have thought through.

But I think that I will drop the cuts/glue/number of pieces characteristics, that are currently in the ODB.

For me (and I think also for many other people) this is a very important point. I prefer my models from one sheet, uncut, unglued and these characteristics might well influence my decision whether to buy a book or not.

[origami_8]

But I think that I will drop the cuts/glue/number of pieces characteristics, that are currently in the ODB.

For me this is one of the most important reasons to buy or not to buy a book, so I would highly appreciate it if you wouldn´t do that.

[Alexandre]

Interesting comments.

But I do not really see what do you mean, you would prefer that a model could be linked to more that one book or only one ?

Yes the pictures are probably one of the most important part of the ODB to recognise the models. I will have to make a nice interface to upload pictures and automatically resize the big pictures.

For the glue/cut/nb of pieces, I thought that it would be a bit of a pain to fill this for each new model, but in fact if I put by default no/no/1 it would not be too much hassle, that's fine.

[origami_8]

you would prefer that a model could be linked to more than one book or only one ?

Preferably to all books it is in, but here comes the problem again that it is hard to find out if the butterfly in book A by author C is the same like the butterfly by the same author in book B. You would need to have all the books to find out, and yes there are some authors that have different models with the same name and without having given them a number to point out which one is which.

[denori]

Hi there,

I'm following this with interest! Alexandre's idea for the optimal solution is indeed the ideal way to do it. I originally rejected this idea for the reasons that Anna and Gerwin mentioned. It is impossible for any individual to know if a model is the same as one already published and the idea was to allow anyone to add to the database. So this had to be dropped.

Starting shape of the paper is already in the database and I added cuts, glue and number of pieces at the request of users on the list, so I think that they should stay. Similarly with the website links.

There is an outstanding problem with number of pieces in that many modulars can be assembled with differing numbers of pieces and there is currently no way for the database to support this.

The database also uses a basic form of tags in the form of two categories. The first is a fixed set, the second is open text. It is possible to search for 'Easter' models or 'Star Wars' as long as people add the text!!

The database also has 5 levels of complexity built in to the system. (Simple, Low Intermediate, Intermediate, High Intermediate and Complex)

Have a look at the Advanced Search features, most of these properties can be used in a search.

I also don't really like the 'individual name' for a model idea. If a creator calls a model 'Elephant' then the database should reflect that. It is not our place to rename it as 'Elephant 4' or 'Elephant 2 from a fish base' any more than we can change the name of a book. It also doesn't reflect what the user will find in the book contents.


And trust me, using photos to determine if two models are the same won't necessarily work. It depends on the skill of the relevant folders

And I agree that wild card searches (and whole word only searches) should be included. And that the whole naming scheme should be rethought (I started with Books, so ISBN made sense, but this has turned into a unique ID for a publication rather than specifically an ISBN. A generic Publication ID should be used and ISBN would then simply be a data field).

If you want to really push the boat out, then users should be able to rate items to allow better statistical analysis. I think that users should be allowed to rate:-
Books
Models
Photographs

But this is a LOT of work!

But it would be fantastic