Time  Nick         Message
23:55 pananohacker logbot: help
23:31 pananohacker Hello.
23:31 pananohacker _
21:34 thd          kados: are you there?
17:03 thd          kados: what they are actually using now is even simpler and anyone can edit the whole record wiki style by just choosing edit or whatever the function is on a record
17:01 thd          http://www.kcoyle.net/temp/PharosSchema+kc.html
17:00 kados        that link doesn't work for me
17:00 thd          :0
17:00 kados        that's mental!
17:00 kados        heh, they licensed it under a draft of a license?
17:00 thd          kados: Karen Coyle's notes on the schema are at  http://www.kcoyle.net/temp/PharosSchema .
16:53 thd          kados: obviously they have it in the source code which is available under the AGPL 3 license which is still only a first draft with one fatal bug at FSF.
16:51 kados        thd: where is the data model defined?
16:51 thd          kados: yet they have the backing of people with real money
16:50 kados        *nod*
16:50 thd          kados: Koha is a few orders of magnitude better than what they have
16:49 thd          s/by/from/
16:48 thd          kados: Karen Coyle has advised them but apparently they have not paid much attention because their XML fields which are populated by LC records do not even have more than one author and many other problems
16:47 thd          kados: their XML schema is simpler than Dublin Core
16:45 kados        not yet
16:44 thd          kados: have you looked at how their data is populated and their XML schema?
16:43 kados        yep, I've seen it
16:43 thd          kados: my other question is have you seen http://demo.openlibrary.org ?
16:39 thd          kados: when I added that file to rel_2_2 a year ago I did not use that syntax
16:38 kados        nope
16:37 thd          kados: is that something new?
16:37 kados        missing the type ext:
16:37 kados        cvs -z3 -d ext:thd@cvs.savannah.nongnu.org:/sources/koha add marc21_simple_bib_frameworks.sql
16:37 kados        you  need:
16:36 kados        ahh, hang on
16:36 kados        did you add your ssh key to savannah?
16:36 kados        nothing
16:35 thd          kados: what was wrong with that syntax?
16:35 thd          this command was issued from my HEAD checkout directory
16:35 thd          kados: I used: cvs -z3 -d thd@cvs.savannah.nongnu.org:/sources/koha add marc21_simple_bib_frameworks.sql
16:31 thd          :)
16:30 kados        (can't do that in CVS anyway)
16:30 kados        permissions haven't changed
16:29 thd          kados: the only thing which I did not do was to try adding again while logging the response
16:28 thd          yes
16:27 kados        cvs commit filename
16:27 kados        cvs add filename
16:27 kados        did you do a cvs add?
16:27 kados        hmmm
16:25 thd          kados: I have been able to add new files in the past.  Have the permissions changed?
16:24 thd          kados: I made an extra column version of the the simple frameworks representing various media types but I have been unable to add it to the misc directrory in HEAD
16:22 kados        sure
16:22 thd          kados: I have a couple of other questions
16:22 thd          I will think about my suggestions from a year ago and propose something tomorrow
16:20 thd          s/ than/,/
16:20 thd          subfields are defined in another
16:19 thd          kados: just to be clear than the fields and current limited indicator support is defined in one table
16:18 kados        :-)
16:18 kados        so I'm not really the one to ask
16:18 kados        and ... I'm not really a database designer :-)
16:18 kados        no, just haven't thought about it much
16:18 thd          kados: you hesitate?
16:16 kados        possibly
16:16 kados        hmmm
16:14 thd          kados: would a new table for adding better support for indicators be necessarily better because it would not break any existing code?
16:11 kados        yep
16:08 thd          kados: are you there?
16:06 thd          kados: adding a new table could not break anything
16:05 thd          kados: should improved support for indicators go where indicators are treated now in the table for the field generally or should they have their own table like subfields?
16:04 kados        right
16:02 thd          kados: the list should obviously start with something for indicator positions similar to what is present for subfields
16:01 thd          kados: given your statement about some code which breaks on reading would that not unnecessarily delay the release?
16:01 kados        I know indicators is one area we could improve in
16:00 kados        well, weve discussed adding columns to the framework, but I haven't seen a list yet
16:00 kados        :-)
15:59 thd          so you are inviting me to break head by suggesting new columns now rather than later?
15:58 thd          hello kados
15:58 kados        hiya thd
13:05 dewey        kados is just a bit tied up
13:05 thd`          kados?