Improvement of the ODB

[wolf]

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

As Daydreamer said in his post above, moderation would be necessary at first. Perhaps after a certain number of submissions, users can then be considered for moderation-free, 'Trusted User' status.

Images would be the way to go for better model identification, but there'll be an issue of bandwidth. Space is not so much a problem, surprisingly, even at 10kb per picture, this is only 320 MB of space. Bandwidth on the other hand, can easily hit a few GBs/month.

A separate wiki-style database for websites would be good, since it changes so often that it'll be easier to let users edit entries on their own and keep things updated.

[Alexandre]

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?

Sorry I did not understood exactly what you mean.
Yes I will not use only one table for the books and one for the models.
I will have a *link* table that contain probably a book_id, a model_id, and a page. I can even add in this table the "type", i mean diagram/CP/PCP (like what you said in a previous post).
I will publish a draft of database when I will really start, in june (2006). Ruby on Rails got a special way to manage the database so I will adapt the structure to RoR too.

As Daydreamer said in his post above, moderation would be necessary at first. Perhaps after a certain number of submissions, users can then be considered for moderation-free, 'Trusted User' status.

hi wolf!
Trusted users/moderators is a good idea.
I will think about how I will manage the versionalisation of the data, I may use http://ar-versioned.rubyforge.org/ that manage to rollback or switch from one version to another version of any entry in a table, and works perfectly. But maybe it will be complicated to display on the website only the not moderated version and wait for a moderator to accept the modifications.
Maybe at the beginning I will just allow a list of trusted users to make the changes, not versioning the data but just make an automatic daily backup of the database. I will make a special page with the "ChangeLog" in all cases, so everybody know who is modifying what. Then I may make a more complex system of moderation.

Images would be the way to go for better model identification, but there'll be an issue of bandwidth. Space is not so much a problem, surprisingly, even at 10kb per picture, this is only 320 MB of space. Bandwidth on the other hand, can easily hit a few GBs/month.

I will buy in june a virtual dedicated server, with 40GB of traffic per months, and 1$/extra GB. It will be ok I think. I do not think that the ODB will be slashdotted/digged regulary.

A separate wiki-style database for websites would be good, since it changes so often that it'll be easier to let users edit entries on their own and keep things updated.

The "free diagrams" project will be a semi-separated thing. It will use some tables of the ODB (like the users tables), but maybe I will use another interface to browse/search in it. We shoud think about this too...
Maybe a very simple structure with Websites--Diagram/CP, and each diagram will got a website_id . I do not think that a diagram could be on more of one website, and we don't have a "page" problem here too. Yes this database may be unmoderated.

[Daydreamer]

Yes I will not use only one table for the books and one for the models. I will have a *link* table that contain probably a book_id, a model_id, and a page. I can even add in this table the "type", i mean diagram/CP/PCP (like what you said in a previous post).

That was exactly what I meant with the table "diagram" or "appearance" all the time. It is in that table where the data which we think is important that is specific to the diagrams only (and not to the model) should be included. Maybe the language (as discussed before) and maybe something like a comment/rating about the usability of the diagram (which probably might be better than the classification handdrawn/computerdrawn because there are very good handdrawn diagrams and also bad computer-drawn diagrams).
And I think if the table is there anyway we can as well use it to differentiate between diagrams and CP.

Also about your comment earlier about having too many (unnecessary) data-fields in the database which would complicate the model-addition-process. These fields can always be optional fields which you can but must not enter. There are always generous people who are willing to spend some time to add this extra data, and we shouldn't restrict our possibilities too much in advance. It's always easier to remove data-fields afterwards, than to add new fields because we discover that something essential was missing.

We should take this opertunity to ask people what they think that the database should include in data (which isn't there now) and which they think is not needed (which is there now). So, I hope some more people will give their opinion about this. This is a database for the Origami community and the features shouldn't be decided by a bunch of very few people alone

[Alexandre]

Excellent, I completly agree with your post.

So yes, any user should be able to rate a diagram/CP. And the rating of the models will just be the average rating of the diagrams/CP of the model.

For the extra data fields, I agree too. We will just have to define a reasonable list of fields.

Yes we should ask to the community, but we should make a quick resume of this big thread before.
I start the resume :


*authors
-first name
-last name
-nationality
-comments [in a separate table]

*books
-author_identifier (the person who make the book)
-ISBN
-publishing date
-comments [in a separate table]
-ratings [in a separate table]

*models
-name
-author_identifier (the person who created the model)
-picture
-paper format (square/$bill/etc..)
-number of pieces (1/2/modular/etc..)
-a list of tags, like "christmas","dinosaur","traditional", etc [in a separate table]
-complexity (simple/intermediate/complex)

*instances of a model
-book_identifier
-model_identifier
-language
-rating [in a separate table]
-comments [in a separate table]
-type (diagram/CP/PCP)
-made with a computer or written by hand
-number of the page in the book
-number of steps ?


So for a basic visitor, if he visit :
-the author page, he will see the details of the author and the list of his books
-the book page, he will see the details of the book, and the list of the models of the book, with their details
-the model page, he will see the details of the model, and in which book it is available, and who wrote the book

[wolf]

So yes, any user should be able to rate a diagram/CP. And the rating of the models will just be the average rating of the diagrams/CP of the model.

Can of worms here: I'd expect that if you do this, you might have a couple of disgruntled authors sending emails to request that the rating be removed, or amended, or somesuch. BT, DT. Not fun! There'll be a need for some disclaimer and a general policy of ignoring such emails.

[Aurèle]

• authors
  • first name
  • last name
  • nationality
  • You could add detailled identity to get a working tool: pseudo (Halle for instance), birth, death etc. (not the credit card number )
  • comments (Really useful ? or maybe generalized to each main tables)
• books
  • author_identifier (maybe distinction beetwen, authour, editor, publisher)
  • book type (collection, book, convention book...)
  • ISBN/ISSN (magazine does have an ISSN)
  • publishing date
  • pages
  • publishing place
  • language (very useful for japanese book, some are in english, some are in jp. )
  • comments (see previous note)
  • ratings (see previous note)
• models
  • name (original)
  • name (translated)
  • author_identifier (the person who created the model)
  • picture
  • paper format (square/$bill/etc..)
  • number of pieces (1/2/modular/etc..)
  • a list of tags, like "christmas","dinosaur","traditional", etc [in a separate table]
  • complexity (simple/intermediate/complex)
• instances of a model
  • book_identifier
  • model_identifier
  • language
  • type (diagram/CP/PCP) is distinction beetwen CP/PCP really usefull ?
  • made with a computer or written by hand
  • page-range
  • number of steps, (if CP, it meaning-less, remove, page-range is a good way)
  • rating (see previous)
  • comments

-the author page, he will see the details of the author and the list of his books
-the book page, he will see the details of the book, and the list of the models of the book, with their details
-the model page, he will see the details of the model, and in which book it is available, and who wrote the book

OK, you must follow some bibliographical conventions in the choice of fields for book I think, like type of author, place and page-number. It is usefull to find a book or to know if it is a booklet or a bible.
If you add some other stuffs to the person table, you give to user more than a diagram database, you offer an tool for know origami world. Interview in ODB is for me insignificant: this tool is not really in usage.

[Alexandre]

for the comments about the author, I think that it will be useful. Comments will not be generalised to all the tables, just to author/book/instance of a model. For all the rating/comments things, if some people start a flamewar the things will change. But I do not think that origamist are extreme trolls like IT geeks (Windows vs Linux etc...)

Yes I can add pseudo/birth/death for an author it is no problem.

For the book, the ISBN field will be in fact a ISBN/ISSN field, good point.

Publishing place is useful ? It would be better to have a "publishers" table, with name,nationality

For the language of the book, I thought that the language of the book will be the sum of all the languages of each instance of models of the book. Any better idea ?

For the original/translated name of a model, it looks very confusing. So when a visitor search for a model name, the ODB will look in both original and translated name ?

Yes PCP is maybe useless, diag/CP is enough.

Page range ? Do we need to know the last page of the diagrams ? maybe, it could be used to know how many pages a diagram take.

What do you mean exactly by bibliographical conventions ?

For the type of book, is book/booklet enough ?

And I look for a good solution to, for example "group" a list of books, like all the "Origami Tanteidan Convention" books. Maybe it could be made easily with a tag in the book table !

And I would be interested to know what is the current rate of update of the ODB, I mean is there many people that update the database ? I am just a bit afraid to create too many fields in the forms, and it may discourage people to add data in the database.

Thanks for the comments

[Daydreamer]

What do you mean exactly by bibliographical conventions?

There are some fields which usually are stated (at least in scientific papers) when quoting another book, that includes (please feel free to correct me since it's been a while since I last wrote a paper...):
Title, Subtitle, Author(s), Publisher (+Location), Year
I have the feeling I missed something, not sure though.
You can check this page here (just one of the many out there):
http://www.brittonkill.k12.ny.us/emerso ... ources.htm

Concerning Publisher+Location, there are publishers with more than one location.

For the original/translated name of a model, it looks very confusing. So when a visitor search for a model name, the ODB will look in both original and translated name?

That would be good in my opinion.

For the type of book, is book/booklet enough?

Well, I would at least add "magazine" as well, since in my opinion a booklet and a magazine is different.

And I look for a good solution to, for example "group" a list of books, like all the "Origami Tanteidan Convention" books.

I don't think that's entirely necessary because you get all the Tanteidan books if you search for "Tanteidan".

I am just a bit afraid to create too many fields in the forms, and it may discourage people to add data in the database.

Have you tried to add a book/models to the ODB recently? You will see that a lot of the fields mentioned in here are already there.

[Aurèle]

for the comments about the author, I think that it will be useful. Comments will not be generalised to all the tables, just to author/book/instance of a model. For all the rating/comments things, if some people start a flamewar the things will change. But I do not think that origamist are extreme trolls like IT geeks (Windows vs Linux etc...)

I agree, it looks like comments on manual pages like php.net or others.

For the book, the ISBN field will be in fact a ISBN/ISSN field, good point.

take care that isbn and issn are two different forming convention, adn that the norm of ISBN change in 2007, with 13 digits.

For the language of the book, I thought that the language of the book will be the sum of all the languages of each instance of models of the book. Any better idea ?

No. The langage of the book is the language of preface, introduction, details... but diagrams could be in english, or other.

For the original/translated name of a model, it looks very confusing. So when a visitor search for a model name, the ODB will look in both original and translated name ?

Yes. Is it really annoying ?

Code: Select all

 SELECT * FROM models WHERE title LIKE foo OR translated-title LIKE foo 

It is better than "Original title (translated title)" as in actual ODB.

Page range ? Do we need to know the last page of the diagrams ? maybe, it could be used to know how many pages a diagram take.

«Please, can you copy me the pages xxx-xxx of this book ?»
page-range is easy to type for a user, more than start-page + total_page.
Total page number can be calculate by the program, it is not a field a user should enter. Page range is very useful in bibliographical references.

For the type of book, is book/booklet enough ?

No, I don't think.Something like bibtex type or other should be usefull, because you haven't the same fields to edit for each type of publication.
it would be something like: book,booklet, unpublished,periodical.
If you use a table for each type, it would be easy to add new type as website or other, because it doesn't change origanization of other table. You can too use one only table for all the type, but deactivate the entries which are not usefull for each type (when a user select a type of publication).

And I look for a good solution to, for example "group" a list of books, like all the "Origami Tanteidan Convention" books. Maybe it could be made easily with a tag in the book table !

Or Origami Tanteidan is a collection (a different type), and the number 11 is only an instance of this type:

Code: Select all

Series (title, publisher, etc.) --- Publication (number, year, pagenumber) --- Diagrams [etc.]

I am just a bit afraid to create too many fields in the forms, and it may discourage people to add data in the database.

I don't think, if you give the form in a few number of different pages as:

• [=]Select book type
  [=]describe the book (title, subtitle?,date,pagenumber,etc.)
  [=]More about authors (different authors and type, selecting it in a list or ading an new one)
  [=]Add diagrams
  [=] Hop !

[origami_8]

For the hand/computer written diagrams, .... 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.

Just had a look at my recently bought books.
Resumé: 10 Handdrawn and 3 with Photo-Instructions
But maybe the more important part is the clearness of the diagrams. I have computer drawn diagrams in some books that are a lot more confusing than well made hand drawn diagrams, so the question would have to be: good quality diagrams or bad quality digrams?

[wolf]

Quality is a fairly difficult thing to measure and is pretty subjective, unfortunately. It's the same with ratings on models and authors, it's quite hard to quantify these things without bias. For model review comments, I'm predicting that it'll quickly degenerate into 'Plz send me diagrams my email is xxx@xxx, thx.'. It'll be nice to be proven wrong, naturally.

My personal opinion is that it's more useful to have a completely objective database - one that deals only with hard data. A separate comments/review database could be built on top of that.

[Alexandre]

Thanks Daydreamer for the precisions
For the ISSN/ISBN, can I use the same field for both ? Wikipedia say that ISBN got 10 to 13 numbers , and ISSN 8. A book can got an ISBN *AND* a ISSN ?

And I probably forgot that a book can have more than one author... I will have to take care of this !!

I am ok for book/booklet/magazine for the type of book.

The langage of the book is the language of preface, introduction, details... but diagrams could be in english, or other.

Hum, but some books got their introduction in 2 languages too... So we would have a list of languageS for the book, and 1 language per instance of model maybe.

page-range is easy to type for a user, more than start-page + total_page.
Total page number can be calculate by the program

This is what I meant in my post

No, I don't think.Something like bibtex type or other should be usefull, because you haven't the same fields to edit for each type of publication.
it would be something like: book,booklet, unpublished,periodical.
If you use a table for each type, it would be easy to add new type as website or other, because it doesn't change origanization of other table. You can too use one only table for all the type, but deactivate the entries which are not usefull for each type (when a user select a type of publication).

What are the differences, when you enter the model details, if it's on a book or on a booklet etc? If a book is unpublished, we just enter the future date of publication (month-year).
For the website type, I will manage online diagrams later I think. it is quite different compared to books.


For the quality/rating/comments, I can start the ODB without that, and add it later. I will not need to change the structure of the DB to add this kind of features.

[Aurèle]

Just had a look at my recently bought books.
Resumé: 10 Handdrawn and 3 with Photo-Instructions
But maybe the more important part is the clearness of the diagrams. I have computer drawn diagrams in some books that are a lot more confusing than well made hand drawn diagrams, so the question would have to be: good quality diagrams or bad quality digrams?

Perhaps it is a good way to specificate
photo/handdrawn/computerdrawn

For model review comments, I'm predicting that it'll quickly degenerate into 'Plz send me diagrams my email is xxx@xxx, thx.'. It'll be nice to be proven wrong,

Yes, it is too a good place to indicate errors in diagrams, etc. but I follow you to say that is not a derterminant part of a project which is information-oriented. Or it must be moderated, and it is a lot of work for maintainers: they have to concentrate their work on objectiv data. And, for asks and help, there are also internation forum and mailing-list...

[wolf]

Yes, it is too a good place to indicate errors in diagrams, etc.

That's a good point, actually. There's already a semi-active origami errata list floating around, this could get incorporated into the model database as well.

[Alexandre]

okay,so with a specific policy of allowed comments, that would be ok.

2 points to talk about :
-the languages of books/instance of models
-the number of authors per book (one or several)

I got only 5 origami books, this is a bit too short to get a global overview for these points.