Improvement of the ODB

[Daydreamer]

Alexandre's idea for the optimal solution is indeed the ideal way to do it. (...) 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.

There's nothing to say against building the database like that, with the possibility to link a model to more than one book. But you have to keep in mind that the most likely situation will be that someone adds an already existing model as a new one so you will have a double entry in the model-table both linked to a different book. So you should think about an easy way to merge two (or more) models to a single entry in the database, an action that probably can only be done by hand, because there might be different data-fields entered in those two models (f.e. a different categorisation/tagging, one model missing the starting size, etc.).
So I would suggest to make the database structure for unique models linked to multiple books, with an easy interface to merge double-entries.
When linking the models to multiple books you should also remember that this linking also has to include if there are diagrams or CP for that model in the book. Because for the same model there might be CP only in one book but full diagrams in another.
(When talking about all this with words I really learn to appreciate the easiness of database diagrams )

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.

Hmmm... these values don't appear in the search results though, and the only way I found to get to them was to click on "Modify?" in the results.
That brings me to a point that definitely needs to be improved: Crosslinking between creators/models/books etc. For example when you are at a creator you can't switch to a book to see what other models are in there. Likewise you can't see details of the models.

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.

A way to fix that would be to allow the "number of pieces"-field to have on the one hand numbers as value but also the value "modular". Or make a separate field for modular yes/no.

[denori]

So you should think about an easy way to merge two (or more) models to a single entry in the database

A neat idea, but it still requires people to *know* that they are the same model!

When talking about all this with words I really learn to appreciate the easiness of database diagrams )

Entity relationship Diagrams are great!!

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.

Hmmm... these values don't appear in the search results though, and the only way I found to get to them was to click on "Modify?" in the results.

I debated about this one and put these values in the results of the Advanced search. It would be VERY easy for me to bring these values into the main search results.

That brings me to a point that definitely needs to be improved: Crosslinking between creators/models/books etc. For example when you are at a creator you can't switch to a book to see what other models are in there. Likewise you can't see details of the models.

Let me know exactly what you're looking for (Although I probably know) because this would be easy for me to do fairly quickly.

A way to fix that would be to allow the "number of pieces"-field to have on the one hand numbers as value but also the value "modular". Or make a separate field for modular yes/no.

Actually I had thought of trying to allow a comma or semi-colon separated list (e.g. 6, 12, 30)

So can I take it that (in the short term) I should
a) add the extra details to the main search results (but possibly reduced font to savce space) and
b) improve the crosslinking.

?

[Alexandre]

Ok, for the problem of shared models in several books, this not a big issue.
When somebody add a book, he add each model in a form with the details of each model, or add the ID of a preexisting model (and the page in the book).
If there is a CP and a diagram, it can be added in the comments of the model for example. I will probably add another caracteristic for each model, diagram or CP. So a diagram and a CP will be 2 differents models.
I will definitavely give the possibility to comment/rate books/authors/models. (Maybe the rating of authors is not a great idea )
If somebody find 2 same models in the database, he edit one of the books, delete the duplicate model and add the ID of the other model and the page.
The ID of each model, books, author will be displayed.
If a model got the ID #456, it will be accessible directly by the adress /model/456. Same concept for authors and books.

The system of tags to classify the models will be more complex, I will have to think about it.

For the number of pieces, what would you prefer ? something like 1/2/modular ? or more choices ?

[Daydreamer]

So can I take it that (in the short term) I should
a) add the extra details to the main search results (but possibly reduced font to savce space) and
b) improve the crosslinking.

I would say the extra details are not necessary in the search results, what I suggest is this:
Have three pages like show_creator, show_model, show_book with all the details for the specific item, and have crosslinks from creator to model, creator to book, book to model, etc...

So a diagram and a CP will be 2 differents models.

But that goes against your idea of having a unique model, it is still the same model but it is differently presented. If you really want the most optimal solution you would have to have the structure somehow like this:

Model ---(1:n)--- Diagram ---(n:1)--- Book

so that in the table Diagram you can have the following data-fields:

• Type: diagram/cp/pcp/...
  Language
  maybe if they are handdrawn or computer drawn
  whatever else might be useful.

If somebody find 2 same models in the database, he edit one of the books, delete the duplicate model and add the ID of the other model and the page.

There should be an easier interface to do that where you won't have to look at one book, remember the ID, go to the other book and edit this other book. Otherwise there are prone to be a lot of errors....

[Alexandre]

For the diagrams/CP/PCP, I will think if it is better to use a different model or the same model. I am not sure. For a model crossed between 2 books, we would have to indicate the ID, the page and the type of model ?

For the language, I think that it will be applied to the book, and not on the model.

Hand drawn or computer drawn ? Do people are interested to know this ? It will be boring to add for each model this caracteritic maybe. I am open to any comment about this.

There should be an easier interface to do that where you won't have to look at one book, remember the ID, go to the other book and edit this other book. Otherwise there are prone to be a lot of errors....

You got a better idea ? If the user can not remember a number like 12756, he can copy/paste the number. And in all cases after adding the book, he will be redirected to the "book page" (/book/128 for example) and he will see if everything is fine.

For the number of pieces I do not think that we need a specific list of possible combinaison of number of pieces (aka 12,16,32 for ex). People use to search for a model that got specifically 32 elements ? What do you think about 1/2/modular ?

[Daydreamer]

For the diagrams/CP/PCP, I will think if it is better to use a different model or the same model. I am not sure. For a model crossed between 2 books, we would have to indicate the ID, the page and the type of model ?

As I stated above you will need a structure like I suggested anyway, since you can have multiple diagrams for one model and also (of course) multiple diagrams for one book, so diagram definitely has to be a separate table in the database. (I don't know about your background in database progamming but a m-n-relation usually is resolved by a separate table.)
And then it would be the most obvious thing to have in this table also CPs linked to the same model. So maybe "diagram" was the wrong name for this table, it would be something like "appearance". The entries of that table would represent something like: Model M (ID) appeared (as diagram/CP, on this page(s), ...) in Book B (ID).

I agree that language probably better is placed into book, but there are also convention books where multiple diagrams in different languages are packed together, so I'm not sure about it.

Concerning model names: If we want to keep the author's original model name this name will in some cases be non-english. I therefore suggest to have two name-fields like "original name" and "english translation".

[Aurèle]

Oops, I haven't read this thread since yesterday...
I am not very fond of a wiki-like db; it may create some problem, as bad identification between two models etc.
Submiting models, books, corrections etc., rating them, search into db, are the work of the user,
but approving entries and adding them into the db should be the work of content maintainers.

So, part of thread discussing about model/diagram should result into something like: if a user find diagrams keyed twice, he fill a form with the id of models in conflict, and the system put this in a 'connection' table. Content maintainers verify the conflict, and if it is proved, models will be linked, if not, it will be remove, and if content maintainers can't verify the assertion (they don't know all the books and all the diagrams), they contact who filled the form to verify this.

You see, I think a system like ODB could not trust all users: I know lot of people who can't fill a form without errors even if they have all informations right in front of their eyes.
Moderators (maintainers) must have a look on each information before adding them into a db.

[malachi]

If you really want the most optimal solution you would have to have the structure somehow like this:

Model ---(1:n)--- Diagram ---(n:1)--- Book

so that in the table Diagram you can have the following data-fields:

• Type: diagram/cp/pcp/...
  Language
  maybe if they are handdrawn or computer drawn
  whatever else might be useful.

Is it common to have diagrams with mulitple languages in the same book? In the ER diagram I am working out (for fun), I would have a Language table with a many to many relationship to Book/Source, although it would be possible to do that at the diagram level, it might add additional complexity to the data entry with very little return.

At this diagram level is where I would add attributes for number of units for a modular thing (to relate to the different number of units actually described in the Source. Also, maybe number of steps and some other details.

It all levels, it might be useful to allow users to provide commentary about the models/books/diagrams/pictures. One of the biggest issues I have when using the database as it currently stands is that I don't know, due to lack of pictures and commentary, much about, say, the level of detail. If I search for "frog" I don't have any idea how different the frog in ODS is from the frog in Origami Dream World until I get both books off of the shelf to see. Worse yet is when I don't own the book yet, so I can't tell if I should even bother to try to find the book.

I think that sorting out the models that have been published multiple times will be a tricky talk, but I think that it's worth it because it is often the case that one publication is out of print and another is not, but I can't be sure if the in print book has the model I'm actually looking for.

Aside from having an easy way to associated images with models, I think easy to create/update tags for models would be the biggest boon.

I'd be perfectly happy to discuss any database schema that is proposed.

[malachi]

Hand drawn or computer drawn ? Do people are interested to know this ? It will be boring to add for each model this caracteritic maybe. I am open to any comment about this.

Some people want to know this because non-computer drawn diagrams can be very difficult to understand. At least ones drown by a computer are consistent.

I have an easier time with computer drawn diagrams with text in a language I understand than with hand drawn diagrams with text I can understand.

[Aurèle]

Is it common to have diagrams with mulitple languages in the same book?

Look at Tanteidan convention book for instance, you have at least japanese, french, english diagrams in original languages.
In XML, you may represent this like the following, which with some XSL and XLINK stuffs should give a good representation with link beetwen book page, author(s) page, model(s) page etc. (Sorry, XML is easier for me than SQL to describe that here.

Code: Select all

 

book lang="jp" id="OTC10"
  author type="publisher" id="nishikawa"/
  author type="editor" id="yamaguchi"/
  publisher id="joas"/
  publication-date year="2004"/
  title lang="jp" main="main"
    [some japanese title] Vol.10
  /title
  title lang="en"
    Origami Tanteidan Convention book Vol.10
  /title
  diagrams
    diagram lang="jp" id="尾長鶏" page-="122" page+="123" /
    diagram lang="es" id="spitfire" page-="152" page+="154" / 
    diagram lang="en" id="brillcat" page-="176" page+="178" / 
    diagram lang="fr" id='loup" page-="194" page+="197" / 
  /diagrams
/book

EDIT: Sorry for HTML-entity, phpBB automagically converts japanese into this...
EDIT2: And I had to remove <and> because phpBB doesn't know what to do with...

[malachi]

Is it common to have diagrams with mulitple languages in the same book?

Look at Tanteidan convention book for instance, you have at least japanese, french, english diagrams in original languages.

Sorry to be a pedant, but that doesn't answer my question. Is it common to have diagrams in multiple languages in the same book? To be more clear, I mean books with some diagrams in one languange and one or more diagrams in a different language, not books where all diagrams have two or more languages.

I realize that there are books where this is true, but to me it's a question of usability. If you require an extra bit of data for all models for each and every book when it only actually matters for, maybe, less than 1% of all books, then it just makes it harder for users to submit the data with very little actual gain. If comments were allowed for diagrams in the book, then any language variance could be noted there, without having much additional encumberance.

That's my point of view, anyway. I know it wouldn't be hard to implement either plan, but it's a question of which is the most useful approach.

[Aurèle]

Is it common to have diagrams in multiple languages in the same book? [...] I realize that there are books where this is true, but to me it's a question of usability.

I think it is common in Convention books, which are not negligible (last French convetion book does have chinese, english, spanish and french speaking diagrams), and in general in collections, not in books with only one author.
If it is a problem of size, the xml example which I presented have an language flag for book and one for each diagrams. If diagrams are in the same language as the book, it is easy to remove the flag in diagrams. For user who fill a form to enter the diagram, it is easy to select another language for each diagram if the gui can give as default value the language of the book.

[Aurèle]

If comments were allowed for diagrams in the book, then any language variance could be noted there, without having much additional encumberance.

Comment field should be use to quality judgement or advices
quality judgment for language in a diagram is not significant (something like 'written in a poor english as my messages ' ? ) as, if a hand-drawn diagram is really incomprehensible for someone, it is a good place to advice other folders.

EDIT: and a diagram reference should be written the most independant it may be, and not in reference with other diagram in the same book, to avoid comments like: "hen by one folder is better than the other hen p. 124 of the book", no ?

[Alexandre]

@Daydreamer

No I will not use one table for the models and one for each occurences of this model. It will duplicate the 32000 models in 2 tables. It will be perfetly fine if we indicate in the comments that a CP for this model is in the book something.

The "language" could be one or several languages, but I am not sure if I will apply the language to a book or a model.

For the name of the model, I will not use an "original name" and "english translation", or it will be a complete pain to add a book in the ODB.

but thanks for your comments, it make me think about things that i may not think about!

@Aurele

You mean that the modifications will have to be approved by some moderators ? I think that the concept of Wikipedia works fine, a list of the last modifications is easily available, and a possibility of rollback in the past is given. The ODB will probably works perfectly with 2 features like this. But I think that I will enforce the users to create an account to edit the ODB.
" I know lot of people who can't fill a form without errors even if they have all informations right in front of their eyes." Yes some people are dumb, but not trusting anybody will make the boring administrative/moderative work too huge. I will have to automatise the most possible tasks (like resizing the pictures) to avoid to annoy too much the moderators.

@malashi

cool, a person that think about the structure with a usability point of view
thks for your comments

@all

For the language, during the addition of a book, at the beggining, I can offer to set the language of the book and the default language for all the models, and after when the user add each model, he can modify the language of the models that are not in the default language of the book.
For example : I want to add the book "origami tanteidan convention 32", so I put as "book language"->"japanese,english". Then I set as default language for all the models "japanese". Then I add one by one the models, and for the models in japanese I do not change the pre-entered language (japanese), but for the english models I set the model language as "english" . Then, in the database, I will keep the book language (jp,en) and the language for each model.
It looks complicated, isn't it ? And it will be even worse when the same model will be in 2 different books in a different language !
It may be better (usability!) to just set the book languages.

For the hand/computer written diagrams, if somebody is ready to set for the 32000 models a hand/computer caracteristic, it's fine. All the new books got computer diagrams, and quite all the books with hand-made diagrams are out of print. I think that it's a waste of time.

If we had 500 children working in a basement all day long to fill 2 tables per model/occurence of the model, to fill the language of each occurence, to fill the english name and the original name for each model, to check each modification of the ODB, and to set the computer/hand type of diagram for each diagram, it would be no problem to implement all of this. But it's not the case. But the ODB can be completly great if I restrict the data to the useful things, and if we trust the users a little bit

I'm open to any comments !

[Daydreamer]

No I will not use one table for the models and one for each occurences of this model.

Well, then tell me how else you will handle in the database that one model appears in more than one book including information about where (on which page) that model is in the book?

You mean that the modifications will have to be approved by some moderators?

That's the way the ODB works now, and I think that it's the only way to keep the database clean.