Improvement of the ODB

[Aurèle]

3 Perhaps we need to stop thinking in terms of "books" and just need to have "collections" of models, this would cover websites and could also expand to include magazines within a subset (in the same table)

Websites are a quite intricated problem. a website may contain links which point to ressources which are not on it. Knowing where begins and where ends the actual content of a website (for instance in term of legacy) is very difficult. It is better to consider the whole web as a collection of ressources, which may be website, files, data or others.

[denori]

Hi David,
I'll answer this lot from the ODB perspective.

1 What is the main "thing" we are recording in this database

Primary function is to answer the question 'Where can I find diagrams for <model>?
Secondary function: provide reliable data about the model and by extension all origami model collections (Good phrase David!)

2 Why do you not just have a single entity table that is authors/ creators and publishers?

The ODB regards the Author of a book and the Creator of a model as separate and as an attribute of the Book or model. There is no separate database of creators. This was a deliberate choice to avoid people having to continually add new creator details.
I also took the decision at the time to ignore the publisher details. Firstly, it's extra data to be added. Secondly, it is 'specialised' data. Few people are likely to worry about the publisher and thirdly even if they ARE worried about the publisher then it is information that can be extracted from the ISBN (unless the book is >30 years old).

3 Perhaps we need to stop thinking in terms of "books" and just need to have "collections" of models, this would cover websites and could also expand to include magazines within a subset (in the same table)

4 Using point 3, it could be expanded to say years for organisational booklets eg volume 2003- mag no 56 page no 23, and for websites
Joe Bloggs homepage- Main origami page- specific url

This is precisely what the ODB does (but I didn't use quite such a nice phrase and consequently the terminology in the ODB is pretty poor)

5 would not worry about "first" and "last" page of model- what use is that?
just have the page it appears on or the specific url.

Again, this is pretty much what the ODB does. However, I generally don't provide specific url details as it is usually regarded as bad manners to 'deep link' into someone's website.

6 complexity of a model or not is very subjective- Some models appear deceptivly simple- an example of this would be Michael La fosse, nothing too hard until you try to finish the model of to look good!
So I would not call many of his models complex- but to get them to look good, that is different- you can't quantify that

Whilst I agree in principle, many books provide the complexity details and many people use it as a guideline. If you ask 200 people whether a model is simple, intermediate or complex, you'll get a fairly consistent answer.
The ODB uses 5 levels (Simple, Low Intermediate, Intermediate, High Intermediate and Complex)

I am more than happy to play the devil's advocate in this process.

Keep up the good work!

[David]

Websites are a quite intricated problem. a website may contain links which point to ressources which are not on it. Knowing where begins and where ends the actual content of a website (for instance in term of legacy) is very difficult. It is better to consider the whole web as a collection of ressources, which may be website, files, data or others.

Could not have put it better myself- A publication is a thing that unless every last copy is destroyed, will be avialable- and can be viewed.
Like you say not so with websites- I have yet to find 30 year old websites being sold in 2nd hand bookshops or on eBay.

And are we agreed that recording the publisher is a waste of time, thanks Dennis.

[Alexandre]

Code: Select all

*authors
-first name
-last name
-pseudo
-nationality ??
-birth (month-year)
-death (month-year)
-personal website

*books
-list of author_identifier (the person(s) who made the book)
-type (book/booklet/magazine/CDROM)
-ISBN/ISSN
-publishing date (month-year)
-quick summary
-comments

*models
-name
-list of author_identifier (the person(s) 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","action"...
-complexity (simple/intermediate/complex)

*instances of a model
-book_identifier
-model_identifier
-language
-comments
-type (diagram/CP/diagram+CP)
-page of the model in the book
-made with computer/written by hand/photodiagram ??

things to think about :

1 do we keep "made with computer/written by hand/photodiagram" ?

2 what about the first name/lastname/pseudo ?
Japanese names are weird, many people are not sure if it's firstname-lastname or the contrary when they see a name.
"Halle" is a pseudo...

3 for the difficulty of the models, i shortened this to (simple/intermediate/complex) because it is really enough i think. any comments about this?

4 what about the websites?
the webmaster is an author ? which info do we keep about each model on a website ? a website is linked with a list of models or with a list of instances of models ? websites data must be quite "light", it is easy to click on the link to check by ourselves the details about the models. websites data will probably be publicly editable.

5 the nationality of the author is maybe useless. maybe it would be better to use an optional "details" field for each author.

6 the model names. do we need an english/translated name, and an original name ?

[Daydreamer]

1. do we keep "made with computer/written by hand/photodiagram"?

I'm not so sure about that, but it is the only objective criterion by which the quality of a diagrams might (not necessarily) be judged.

2 what about the first name/lastname/pseudo?

It might be enough to have one name-field in which the full name is mentioned.

"Halle" is a pseudo...

Yup his real name would be "Carlos González Santamaría" which rises the additional problem of multiple first-names, but I guess we can put them all together in first-name.
Also I don't know of any Origami creator except Halle that uses a pseudo, so one name-field for the Author might be more than enough.

3. For the difficulty of the models, i shortened this to (simple/intermediate/complex) because it is really enough i think. any comments about this?

Since we already have 5 levels of detail in the current DB I would keep it like that. Also in what way would you merge the 5 levels into your 3? A low intermediate level might either fit into simple or into intermediate (similar for high intermediate).

the webmaster is an author?

Yes.

Which info do we keep about each model on a website?

The model info is the same as the info for models in books, the same database table should be used.

a website is linked with a list of models or with a list of instances of models?

The same model might appear as model in a book as well as on one (or more) webpage(s). Therefore it should be an instance of models for a website (and as said before the same model-table used as for model in books)

5. The nationality of the author is maybe useless. maybe it would be better to use an optional "details" field for each author.

This details field would be exactly what the "Biographical Details" in the current DB is. I think it is enough (taken that many people don't bother to write anything in there anyway).

6. Do we need an english/translated name, and an original name?

Yes.

To sum it up, we should try to keep ALL the data that is in the current DB, because removing any fields that are already there means the loss of data that has been added over several years, and in my opinion it would be a pity to lose it.

Btw, you are still missing the "cuts" and "glue" fields in your database structure.

[wolf]

Since we already have 5 levels of detail in the current DB I would keep it like that. Also in what way would you merge the 5 levels into your 3? A low intermediate level might either fit into simple or into intermediate (similar for high intermediate).

I'd prefer 3 levels as well, with 'simple' consisting of the current simple and low intermediate levels, 'intermediate' being intermediate and high intermediate, and 'complex' as it is.

[saj]

With regards to recording model-complexity data, I think we should keep it at the 5 levels we have now. This will ensure we do not loose this information from the database.

It would be relatively easy to program the output such that all varities of intermediate are output as 'Intermediate'.

I think we should also start talking about the design of the website. When Dennis and I originally commisioned the ODB website the colours mirrored that of my personal website. Back in the day, tables were in and the must use design tool. Now they hinder usability and of course make the pages bulky to load.

I have been trying to redesign the site, hopefully porting it over to the wonderful world of standards compliant code (xHTML, CSS and DOM). I'm also looking to make the colours a little brighter; primary white.

Saj

[Daydreamer]

Hmmm.... I'm wondering how you are planning to display search results, etc without the use of tables....

(PS. I still think that tables are the best )

[wolf]

With regards to recording model-complexity data, I think we should keep it at the 5 levels we have now. This will ensure we do not loose this information from the database.

True, agreed; it'll be unfair to those who've already put in the hard work filling out this information on the existing models!

Back in the day, tables were in and the must use design tool. Now they hinder usability and of course make the pages bulky to load.

I'll disagree here; tables are still a great way of partitioning text. Many websites still use them with zero borders to layout different parts of a page.

Keeping the main page of the ODB clutter-free will be good. Right now, there's too much stuff there; it also takes a while to load, presumably this is caused by the need to extract 'recent searches' and other data. A lot of this, while nice for the casual browser, become additional distractions for a user looking for a specific model.

There's also too many fillable boxes (what's the 'cats' checkbox do?); I think these should be kept to a minimum. Three fields (designer, model, book) would be sufficient. Do you have statistics on how often each of the existing search fields is used? I'm guessing model would be the one with the highest utilisation, followed by author. ISBN searches are probably low so they can be stuffed in the advanced search section.

[saj]

I'll disagree here; tables are still a great way of partitioning text. Many websites still use them with zero borders to layout different parts of a page.

Of course we'll still use tables to hold data; but using tables for the design generally isn't normally a good idea. I'd agree lots of website still use them for layout purposes, but making a true CSS styled website will mean that we can make lots of amendments without having to change the main files. To see an example of CSS goodness, head over to the CSS Zen Garden. On this site, the physical HTML code is always the same, it's only the style sheet which changes.

I'm unsure whether we access to those form of stats (relating to form use), however Dennis might be able to enlighten us here. The 'Cats' tickbox I imagine stands for 'Categories'.

Saj

[Aurèle]

4 what about the websites?
the webmaster is an author ? which info do we keep about each model on a website ? a website is linked with a list of models or with a list of instances of models ? websites data must be quite "light", it is easy to click on the link to check by ourselves the details about the models. websites data will probably be publicly editable.

Firstly, if I put a link to http://langorigami.com/art/plants/rose_cp.pdf on my website, it is not true that this CP is ON my website : I don't host the file, I have not asked permission to reference this CP as a part of my website.

Secondly, websites (as a collection of webpage or ressources) are already presents into DB in authority table, which may contains not only physical persons, but institutions, associations, groups too.

So, what about referencing an URI for each ressources (not to a website, but to a pdf, an image, a webpage with a list of photos if the diagram is multi-picture etc.) ? It avoid insertion of non origami-related website, and preserve the integrity of the data contained by ODB ?

Last, it could be very easier to add an engine which verify if the ressource exists or not, and if two years later it does exist too.

[denori]

Hi there,

I'll try to answer a few of these:-

Names are a pain! I started with a single name format and regretted it within a couple of months. Searching and data input will be MUCH more reliable if two fields are used, one for FAMILY name and one for GIVEN name (e.g. my family name is Walker and my given name is Dennis. Another example; family name: Nishikawa, given name: Seiji) Avoids the whole first name/ second name confusion! And the search could check both anyway!! (And just ignore pseudonyms, or put them in as part of the GIVEN name!)

Diagrams on webites:
Saj and I decided that diagrams on websites are only listed on the HOST website, i.e. links don't count. You can put your website on the ODB, but don't add diagrams that aren't actually hosted by you.
Adding links directly to the diagrams, while convenient, is regarded as rude. The equivalent is to rip only the pages you want from a book as opposed to picking the book up and flicking to the right page.

Website checking:
Eileen Tan sent me details on how to do this but I haven't done it yet. people adding websites that have nothing to do with origami is more of a problem. (Vietnamese adverts?????)

'Cats' does indeed stand for Categories. e.g. if you search for Christmas, then all models with 'Christmas' in the name will be found. If you also check the 'Cats' box then all models with 'Christmas' in the name or the Categories will show up. And modifying model details allows you add any category you want to the Sub-Category Field. THis is equivalent to the tags that Alex is talking about

But I agree that ISBN search is pretty useless on the front page. I'll move it to the Advanced area only.

I also have a de-clutter idea that I may try out. But I think that the link to the forum should remain on the front page

And I like tables too . They're easy to maintain. And I don't see how they're bulky to load. It's the data in them that takes the time and that won't be changing!

I'd drop the diagram quality issue, partly because I don't think anyone really cares, but also because it raises a deeper issue. If you want a separate model table, then each instance of a model that has different diagrams will have to appear in that table!!! In short, model X could be in Book Y but with hand drawn diagrams, but also in book Z with computer drawn diagrams. Please drop this field. It adds too much complication for too little benefit.

I agree that a generic 'Biographic Details' is enough. (I've had offers to help me get this going, particularly from Boaz and Ravi, but it hasn't taken off yet!). So no need for birth/death/nationality etc.

I also agree that we need an english translation and the original name (as published in the collection).

[Daydreamer]

Just an idea that somehow managed to sneak its way into my thoughts right now:
Since we have the "My Library" function, wouldn't it be an idea to add a feature like "Ask question to book-owners" so that if you have a specific question about the book (f.e. about the quality of diagrams ^_^) you have a form to send it and the question will be forwarded to all the people who have added the book to their library?

On second thought this feature might be misused for diagram requests....
Also, if people have specific questions they can always ask on the forum as well

[saj]

I guess it's ironic that I mention that tables take longer to render etc when the forum makes heavy use for them! New database system new design (and I'm talking about a radical overhaul, just little details).

Go on Dennis, you know you want to

[saj]

On second thought this feature might be misused for diagram requests....

I think you're right here mate. I was also thinking of better Amazon UK|FR|DE|US intergration, rather than the box on the left we can have a URL purchase field so that users can buy the book directly from Amazon.

I was also thinking of smart searches, where users can bookmark their results (this is possible at the moment too, but most users used the 'cloaked' version of the address). Intergrating RSS into the news section would be nice, as well as a subscribeable iCal link (for us Google Calendar users). We could do this by opening a Origami Database Google account.

Saj