libdb-develop Mailing List for LibDB
Status: Inactive
Brought to you by:
morbus
Menu
▾
▴
libdb-develop — Developer discussions and bickerings.
You can subscribe to this list here.
| 2004 |
Jan
(48) |
Feb
(58) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(29) |
Aug
(36) |
Sep
(5) |
Oct
(1) |
Nov
(32) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
(4) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Morbus I. <mo...@di...> - 2006-08-21 17:29:42
|
Issue status update for=20 http://drupal.org/node/77542 Post a follow up:=20 http://drupal.org/project/comments/add/77542 Project: LibDB Version: cvs Component: User interface Category: bug reports Priority: critical Assigned to: Anonymous Reported by: karun211 Updated by: Morbus Iff Status: active LibDB is no longer being maintained, and it most assuredly won't work with the latest Drupal core. Even if you downgraded to a working version of Drupal core, there's nothing to shout about - it was entirely unfinished. Morbus Iff Previous comments: ------------------------------------------------------------------------ Mon, 07 Aug 2006 21:30:53 +0000 : karun211 All i get when i click on libdb module is blank screen. Can you guide me through ? thanks. ------------------------------------------------------------------------ Mon, 21 Aug 2006 17:26:05 +0000 : kdorff I also get just a blank screen on a new install to DruPal 4.7.3. I installed per instructions, enabled the module for admin, and go to LibDB via admin | libdb and I get just a blank screen. I tried going to the libdb.com and libdb.com/install but both URLs seem inactive. |
|
From: kdorff <mo...@di...> - 2006-08-21 17:26:25
|
Issue status update for=20 http://drupal.org/node/77542 Post a follow up:=20 http://drupal.org/project/comments/add/77542 Project: LibDB Version: cvs Component: User interface Category: bug reports Priority: critical Assigned to: Anonymous Reported by: karun211 Updated by: kdorff Status: active I also get just a blank screen on a new install to DruPal 4.7.3. I installed per instructions, enabled the module for admin, and go to LibDB via admin | libdb and I get just a blank screen. I tried going to the libdb.com and libdb.com/install but both URLs seem inactive. kdorff Previous comments: ------------------------------------------------------------------------ Mon, 07 Aug 2006 21:30:53 +0000 : karun211 All i get when i click on libdb module is blank screen. Can you guide me through ? thanks. |
|
From: karun211 <mo...@di...> - 2006-08-07 21:36:55
|
Issue status update for=20 http://drupal.org/node/77542 Post a follow up:=20 http://drupal.org/project/comments/add/77542 Project: LibDB Version: cvs Component: User interface Category: bug reports Priority: critical Assigned to: Anonymous Reported by: karun211 Updated by: karun211 Status: active All i get when i click on libdb module is blank screen. Can you guide me through ? thanks. karun211 |
|
From: William D. <bu...@po...> - 2005-05-05 02:11:23
|
On 3 May 2005, Morbus Iff wrote:
: Yeah, MySQL 4 has been the only version I've tested that code on, so it
: probably is some sort of new reserved word in MySQL 5. I'll throw it on
: the TODO list to change. I keep itching to come back to the code, but
: I've recently now picked up a new ('nother) writing gig for O'Reilly,
: and am working on a game engine for Drupal too.
You may get some more interest in it over the next little while. At the
FRBR workshop at OCLC in Dublin OH earlier this week, I mentioned it and
some people were interested. I said it was a beginning, very early,
implementation of FRBR built right from the spec, by a non-librarian, for
people to catalogue their personal libraries, and I had it running on my
laptop. That provided a contrast to OCLC, who've been FRBRizing their
enormous WorldCat catalogue by using a twenty-four-node Beowulf cluster of
dual CPU Linux boxes. I showed it to a couple of people and a couple of
others made a note of the name.
Bill
--
William Denton : Toronto, Canada : http://www.miskatonic.org/
|
|
From: Morbus I. <mo...@di...> - 2005-05-04 00:28:19
|
> Since that's the only place that the condition table is mentioned, there
> was nothing in the way of renaming it to condition1. That went through
Yeah, MySQL 4 has been the only version I've tested that code on, so it
probably is some sort of new reserved word in MySQL 5. I'll throw it on
the TODO list to change. I keep itching to come back to the code, but
I've recently now picked up a new ('nother) writing gig for O'Reilly,
and am working on a game engine for Drupal too.
--
Morbus Iff ( a blivet is 11 pounds of manure in a 10 pound sack )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
|
|
From: William D. <bu...@po...> - 2005-04-25 00:32:18
|
On 24 April 2005, William Denton wrote: : # mysql -u drupal -p drupal < libdb/libdb.mysql : Enter password: : ERROR 1064 (42000) at line 24: You have an error in your SQL syntax; check : the manual that corresponds to your MySQL server version for the right : syntax to use near 'condition TEXT, treatment TEXT, scheduled_treatment : TEXT, access_restrictions TE' at line 1 Since that's the only place that the condition table is mentioned, there was nothing in the way of renaming it to condition1. That went through without trouble. Bill -- William Denton : Toronto, Canada : http://www.miskatonic.org/ |
|
From: William D. <bu...@po...> - 2005-04-24 17:46:13
|
I tried to install LibDB today and ran into a problem. Drupal 4.5.2, PHP 4.3.11 and MySQL 5.0.3 are working fine on my FreeBSD 5.4 box, but when I tried to work in the LibDB module from the current libdb-cvs.tar.gz, I got this: # mysql -u drupal -p drupal < libdb/libdb.mysql Enter password: ERROR 1064 (42000) at line 24: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'condition TEXT, treatment TEXT, scheduled_treatment TEXT, access_restrictions TE' at line 1 The offending line is: CREATE TABLE libdb_item ( id CHAR(20) NOT NULL, manifestation_id CHAR(20) NOT NULL, provenance TEXT, marks TEXT, exhibition TEXT, condition TEXT, treatment TEXT, scheduled_treatment TEXT, access_restrictions TEXT, INDEX(id,manifestation_id) ) TYPE=MyISAM; I broke it down to just create the id and manifestation_id columns, which worked, then added columns one by one, and the problem is column named condition. In the manual, section 19.2.10 discusses conditions, and there's an example: DECLARE condition_name CONDITION FOR condition_value I looked through the description of changes from 4 to 5 but didn't see any mention of a condition keyword, but I could have missed it. I assume this is something new from MySQL 4 to 5 and LibDB was built with 4? I can easily drop 5 and go to 4, but I thought I'd check to see if this is indeed the problem. Thanks, Bill -- William Denton : Toronto, Canada : http://www.miskatonic.org/ |
|
From: Bruce D'A. <bd...@fa...> - 2005-02-19 18:20:47
|
On Feb 19, 2005, at 12:59 PM, Morbus Iff wrote: > The FRBR spec contains numerous suggested fields for books, serials, > and audio materials, but I've not included those in the actual tables, > as you know, because they wouldn't have actually been used (for my > initial purposes, etc.). But, "genre" in LibDB is being handled with > the "concept" table, which is a Group 3 entity in FRBR. The plan, once > movies were "done", was to simply add the media-specific fields to the > relevant tables (page numbers to manifestations, etc.). Is it technically possible to do as I was suggesting though? To have that community-specific content broken out in to separate files? > With that said, and with that company no longer "bugging" me to get > something done, I'm not sure I'll have "time" to work on LibDB for a > very long time, if at all. The original impetus is gone, there are > other projects that are taking up a lot of my effort and, though there > was a lot of interest in the Drupal world for it, there were no > additional developers who had the libtech knowledge to do it "right". I guess that's the way things go. I do think it would be valuable -- if you can find a bit of time -- to consider the above, so that the core schema just represented the logic. If someone comes along wanting to do this sort of project (maybe me in a year or two), then I could just point 'em to the schema. There's are probably 50 LAMP bib projects out there, almost all of which start and end with bibtex. I'd love to give them a ready-made alternative. Bruce |
|
From: Morbus I. <mo...@di...> - 2005-02-19 17:59:30
|
> Things are quiet here. Looking at the SQL schema again, is it possible > to break out the genre/media-specific content into separate files? A > lot of the bulk of the schema is just stuff specific to people > cataloguing movies, and I don't want most of that stuff in my db if I'm The FRBR spec contains numerous suggested fields for books, serials, and audio materials, but I've not included those in the actual tables, as you know, because they wouldn't have actually been used (for my initial purposes, etc.). But, "genre" in LibDB is being handled with the "concept" table, which is a Group 3 entity in FRBR. The plan, once movies were "done", was to simply add the media-specific fields to the relevant tables (page numbers to manifestations, etc.). Unfortunatley, I'm not sure what is going on with LibDB anymore. I've had no time to work on it, and the company that I /was/ working on this for has gone with a "quick" alternative that I set up in a few hours (for the probably-live-next-week demo, see http://cinema93.com/movies). Unfortunately, this "quick" alternative was a "just get it done for the mundanes and the non-libtechs", so it has very little merit for those interested in the original goal of LibDB. With that said, and with that company no longer "bugging" me to get something done, I'm not sure I'll have "time" to work on LibDB for a very long time, if at all. The original impetus is gone, there are other projects that are taking up a lot of my effort and, though there was a lot of interest in the Drupal world for it, there were no additional developers who had the libtech knowledge to do it "right". -- Morbus Iff ( anything else in the box, pandora? ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Bruce D'A. <bd...@fa...> - 2005-02-19 17:23:36
|
Things are quiet here. Looking at the SQL schema again, is it possible to break out the genre/media-specific content into separate files? A lot of the bulk of the schema is just stuff specific to people cataloguing movies, and I don't want most of that stuff in my db if I'm interested in texts instead. Perhaps then I could have a file for marc relator terms. Same with concepts. Also, Morbus, if you can find time sometime, could you please show what an SQL record example (maybe by adding to the mysql_sample.sql file) would look like for a magazine article? It might help me wrap my head around how it should work (where to put the page and volume numbers, etc.). Bruce |
|
From: SourceForge.net <no...@so...> - 2005-02-16 07:19:05
|
Bugs item #1123728, was opened at 2005-02-15 23:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622140&aid=1123728&group_id=98818 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: deleting annotation - sql error message Initial Comment: user error: Unknown column 'role_type_id' in 'where clause' given when deleting an annotation, but seems to work ok though (as a drupal module) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622140&aid=1123728&group_id=98818 |
|
From: Morbus I. <mo...@di...> - 2004-12-01 04:41:49
|
Project: LibDB Version: cvs Component: Code Category: tasks Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: active We don't do any input checking on the $id's we receive. We should. Function should check that the $id is twenty characters long, and consists of alphanumerics only. It should return 0 on failure, and 1 on success. It should also be used in almost every function that accepts an $id as a parameter. Which is, like, all of 'em, g-thang. Morbus Iff -- View: http://drupal.org/node/13730 Edit: http://drupal.org/project/comments/add/13730 |
|
From: Bruce D'A. <bd...@fa...> - 2004-11-30 16:38:59
|
On Nov 29, 2004, at 10:33 PM, Morbus Iff wrote: > The goal here is to utilize the database's ability to handle dates, > but also keep the user's original raw string around. Sounds good! Bruce |
|
From: Morbus I. <mo...@di...> - 2004-11-30 03:33:36
|
> That would seem to fit within your thinking. I still wonder if it would > better to add a third option for the point that would allow indication > of "March 12, 14, 19". Well, it can - the actual PHP code will handle this transparently, such that someone entering "1999" for a date would automatically have that put into date_raw, and 1999-01-01 and 1999-12-31 in date_start and date_end respectively. Likewise, a date entered of "1999-04" would have that stored in date_raw, 1999-04-01 in date_start, and 1999-04-31 in date_end. The goal here is to utilize the database's ability to handle dates, but also keep the user's original raw string around. -- Morbus Iff ( that's crazier than a sack of ferrets at a hoe-down ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Bruce D'A. <bd...@fa...> - 2004-11-30 03:03:35
|
On Nov 29, 2004, at 6:21 PM, Morbus Iff wrote:
> Instead of simply an "annotation" column, however, there'd be three
> content columns: date_start (YYYY-MM-DD), date_end (YYYY-MM-DD) and
> date_raw (a string).
I was just reminded of something I've seen in LoC schema that may be of
relevance:
<temporal encoding="w3cdtf" qualifier="approximate"
point="start">1919</temporal>
So a range is indicated by this I guess:
<temporal encoding="w3cdtf" qualifier="approximate"
point="start">1919</temporal>
<temporal encoding="w3cdtf" qualifier="approximate"
point="end">1923</temporal>
That would seem to fit within your thinking. I still wonder if it
would better to add a third option for the point that would allow
indication of "March 12, 14, 19".
Of course, we still get back to the fact that database dates are poor
representations of bibliographic dates. It's a *very* small minority
of books, movies, records, magazines, etc., etc. that ever have a date
like YYYY-MM-DD associated with it.
Bruce
|
|
From: Morbus I. <mo...@di...> - 2004-11-29 23:21:42
|
Project: LibDB Version: cvs Component: Code Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Morbus Iff Status: active I've been thinking about this a lot, and I'd like to bounce one possible implementation off your collective heads. In reviewing the database schema, one of the things I don't address is that the FRBR spec mentions that a WEMI could have multiple dates, whereas the model only allows one per Group 1 Entity. The following possible revision allows an unlimited number of dates for any type of record (which follows the FRBR Final Report more closely) - in effect, "dates" become a special type of "annotation". There'd be two new tables: libdb_dates and libdb_dates_types, and they would be the exact same columns and intent as libdb_annotations and libdb_annotations_types (see the database schema for a refresher: http://libdb.com/node/2). Instead of simply an "annotation" column, however, there'd be three content columns: date_start (YYYY-MM-DD), date_end (YYYY-MM-DD) and date_raw (a string). This would allow: * an unlimited number of dates per "thing". * an unlimited number of types of dates. This flexibility allows handling of the "Lord of the Rings", or other fictional date system too. Just define a new "date type" of "Middle-earth Time". Then, when you're assigning a "Middle-earth Time" date to a record, you'd ignore the date_start and date_end (which assume YYYY-MM-DD dates) and use the date_raw instead, filling it with whatever string you need it to be. (The onus of sorting the fictional dates properly then get pushed onto the cataloguer, not us). There are some concerns, however. The first concern I have about this possible implementation is some planned accountability to the system. In the next revision of the database schema, there are plans to include a "date thing was created" and "date thing was modified", such that we can properly show changes in the Drupal "tracker" system (see http://libdb.com/tracker for an example). Since there are database integrity things and are NOT really necessary to the record itself, I'm not sure if they should belong in the libdb_dates table, from a cataloguer/"useful export data" position. It would certainly be easy and "cleaner" to put them in there (and that's probably where I'll lean toward come implementation), but I'm still not sure it's "right". The second concern is the "extra" fields that aren't immediately necessary. In most cases, you really only need that "libdb_manifestation" "12345" has a "date_type" "datereceived1234", and the values of "start", "end", and "raw" - there's really no need for a "referent_table" and "referent_id" as libdb_annotations and libdb_annotations_types require. The one time that I do see a need for them, and why I suggested mimicking libdb_annotations instead of, say, libdb_identifiers, is for a loaning system: "libdb_manifestation" "12345" has a "date_type" "dateILoanedIt2345", values of "start", "end", and "raw", and a "libdb_person", "Kevin Hemenway" - who you actually loaned the manifestation to can be the referent. In retrospect, however, I'm thinking that a "loan" may be better as merely a libdb_relationship, and these libdb_dates would better be represented as special types of identifiers, not annotations (but then, would we need to go overboard with "date I bought", "date I threw away", "date I watched again" relationships?) Morbus Iff Previous comments: ------------------------------------------------------------------------ August 18, 2004 - 09:18 : Morbus Iff There are a few qualms I have with the current data model's date system, and it's all due to implementation, not necessarily bad intent. The intent is innocent: dates should be in the form of YYYY, YYYY-MM, or YYYY-MM-DD. The goal here is to say that a "movie came out in 1997" or, if you know the exact date of theatrical release, "1997-06-02". Same sorta thing with birthdays: you may approximately know that someone was born in "1817" or even in "1817-04", but not the exact moment in time. The almost immediate problem with the above formats, however, is the lack of support for "A.D. 143" or "B.C. 23" (though I hesitate to label that a critical issue.) Technically, "A.D. 143" could be referenced as just "143" (YYY, not YYYY), but I'm not sure the underlying database will support that early of a year - regardless, MySQL would convert a date of "AD 43" ("43") to "1943", which isn't what we want. We'd have to zeropad non-YYYY dates ("0143" and "0043"). This doesn't help us with B.C. dates at all. See also http://dev.mysql.com/doc/mysql/en/DATETIME.html: "The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'. (``Supported'' means that although earlier values might work, there is no guarantee that they will.)" Irregardless of how early a date is, our current data model expects to receive YYYY-MM-DD and ONLY YYYY-MM-DD - there's no capability for just YYYY or YYYY-MM. After some discussion on a #mysql IRC channel, it appears that the only way to handle ranges (where "1997" is a range of ["1997-01-01" to "1997-12-31"] and "1997-04" is ["1997-04-01" to "1997-04-31"]) is to have two database fields: date_start and date_end. It'd then be necessary in our code to create the ranges ourselves (from a user-entered "1997"). This is the only way to do the "right" thing, with proper database columns, and use of WHERE date/time clauses (WHERE date_start > '2004-04-25' for example). * Is this the "right" thing to do? * What about fictional dates ("Shiresmoon 23")? Affected tables: libdb_work libdb_expression libdb_manifestation libdb_person libdb_corporate_body libdb_events. ------------------------------------------------------------------------ August 18, 2004 - 16:23 : Little Nemo All right, I'll bite. Here's a superfluous oneshot bone-head suggestion. A column in each table to be used as a date modifier that can only be represented as AD OR BC in a pull down menu. WARNING - This would require the user to know the difference between BC and AD. :p I'm not sure what the column should be identified as in the schema however. Perhaps "date_type"? ------------------------------------------------------------------------ August 18, 2004 - 16:36 : Little Nemo Just reread this thread after posting. Using my suggestion would of course alter this: WHERE date_start > '2004-04-25' to this: WHERE date_start > '2004-04-25' AND date_type = 'AD' Oh and insofar as fictional events are concerned, if someone reallly wants them, I'm sure they can convert them to "actual" dates. ------------------------------------------------------------------------ August 24, 2004 - 17:28 : Little Nemo Regarding this post: One can't reasonably assume that a periodical/serial with a publication date of Nov/Dec actually took 2 months to produce, so why not simply assign the publication date as 2004-11-01? The publication couldn't have been produced any earlier right? As for Spring, why not 2004-03-21 (assuming the publisher is in the Northern Hemisphere)? I just don't think altering the code, much less the db, to get the dates "technically right" makes much sense when one can make a reasonable estimation. I think we need to work with what we've got, and what we've got (I think) is good enough. At least for now. And if anyone truly wants to know "fictional dates" I'm sure they can convert them to "normal" calendar dates. LOTR fans I'm looking at you. -- View: http://drupal.org/node/10160 Edit: http://drupal.org/project/comments/add/10160 |
|
From: Bruce D'A. <bd...@fa...> - 2004-11-29 22:59:26
|
Can I ask that people post further thoughts on the blog? I'm trying to get people from different projects involved in the discussion, and it's actually been helpful. On that, I just had an idea in response to one of those comments (thanks Rick!), which is to use existing ids along with the info scheme. E.g. "info:lccn/n78089035". See: http://info-uri.info/registry/docs/misc/faq.html. So if I'm citing a book, I might do: <citation><biblioref linkend="info:lccn/n78089035"/></citation> .. if a journal article with a DOI: <citation><biblioref linkend="info:doi/10.1000.10/12345"/></citation> I think I like this! AFAIK, it should be fairly easy to process with XSLT; without any significant performance penalty (at least I hope!). Anyway, blog entry is at: http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2004/11/27/ citation-ids Bruce |
|
From: Morbus I. <mo...@di...> - 2004-11-29 17:13:11
|
> I also wanted to mention an oddity about the FRBR paper that > you refered me to. There is a bizarre blunder in this paper > in the (mis-)usage of the word "Equinox". Apparently the > author has confused it with the word "Epoch", i.e.: Here is the response from the FRBR list: -------- Original Message -------- Subject: Re: [Fwd: [libdb-develop] FRBR paper uses wrong word?] Date: Mon, 29 Nov 2004 11:27:17 -0500 From: Barbara B Tillett <bt...@lo...> To: <mo...@di...>, <fr...@in...> Just wanted to point out in cartographic cataloging that the equinox is expressed as a year that is given following coordinates for celestial charts, and in Anglo-American Cataloguing Rules one may also add a statement of the epoch when it differs from the equinox. The definition of equinox is indeed the third one listed by your colleague below. Actually in the Cartographic materials, 2nd edition the definition as taken from the United States Defense Mapping Agency is: "One of two points of intersection of the ecliptic and the celestial equator, occupied by the sun when its declination is 0 degrees." And the rules go on to say this is recorded as a year. There is no confusion with the word epoch. You may wish to see an example under AACR2 rule 3.3D2. I can't do superscripts with this email message... FRBR has it right (see 4.2.12 where it is defined). - Barbara Tillett -- Morbus Iff ( drowning in data, bereft of knowledge. ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: <ar...@uw...> - 2004-11-29 15:42:50
|
Bruce writes: "So how do we make this work in an internet-enabled collaborative context?" and I wonder about candidates for hosting a globally accessible and low barrier registry to avoid clashing namespaces. I have been thinking about this in terms of trust networks and the use of FOAF (Friend Of A Friend), and have been turning to the Open Directory Project (ODP) <http://dmoz.org> for subject URIs (see example at the end). The CiteSeer project is pretty amazing, and is very citation-centric, but they have been dealing with a lot of system load issues. I also wonder if OCLC might also be a possibility, they do something like this for Names already, for example: <http://errol.oclc.org/laf/nr2003-18130.html>. art --- <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:trust="http://www.perceive.net/schemas/20020725/trust#"> <foaf:Person> <foaf:nick>morbus</foaf:nick> <trust:trustsHighly> <foaf:Person rdf:about="#Morbus_Iff"> <rdfs:subject rdf:resource="http://dmoz.org/Computers/Programming/Languages/Perl/" /> </foaf:Person> </trust:trustsHighly> </foaf:Person> </rdf:RDF> |
|
From: Morbus I. <mo...@di...> - 2004-11-29 15:34:05
|
> I also wanted to mention an oddity about the FRBR paper that > you refered me to. There is a bizarre blunder in this paper > in the (mis-)usage of the word "Equinox". Apparently the > author has confused it with the word "Epoch", i.e.: I'll forward this off to the FRBR mailing list. For what it's worth, there is a WG for the FRBR, and there are numerous mailing list / conference only suggestions that have not yet made it into a revised Final Report. There is a list of TODO's that the WG wants to address, but the most recent conference suggested that "2003/2004" was a "disappointing" year because little actually got done. See: http://www.ifla.org/VII/s13/wgfrbr/wgfrbr.htm http://www.ifla.org/VII/s13/wgfrbr/listserv.htm -- Morbus Iff ( drowning in data, bereft of knowledge. ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Morbus I. <mo...@di...> - 2004-11-29 15:27:33
|
> Hi Morbus (and others), Sorry for taking so long to respond. I get in these email ruts where the Inbox keeps getting larger and larger, and I keep finding more and more work to do to stop me from answering it all. I've sent 50 messages out so far this morning, so I'm making some nice headway ;) > I have made an attempt to read the Perl code. Well, all I > can say is, I *thought* I had learned Perl, but I seemed to > have forgotten what I learned. Your comments and program > file style are a great relief from the usual hacker fare, > though -- thank you, I really respect that! Thanks - I get that a lot, actually :) As Bruce said though, the code has moved to PHP. You can see my rationale for doing so here: http://libdb.com/why_drupal. Long story short, I felt an OPAC/CMS was more powerful and ultimately useful than just OPAC, and I really had no desire to make a new CMS. Drupal had blown me away when I first implemented it for Gamegrene.com, and it was a perfect fit, IMO, for LibDB. The new CVS for LibDB is: http://cvs.drupal.org/viewcvs/contrib/contributions/modules/libdb/ And you can see the latest module code (libdb.module) in there. Here's hoping my PHP code is remotely like my Perl <g>. The code is documented with Doxygen, which allows me to automatically generate an API/HTML export. You can see that here: http://www.libdb.com/developer/api > (or I'm not looking at the right bits), and I'm wondering > what it's for in a general way. I wonder if I need to That code, and ultimately, the current Drupal code doesn't do much - refer to the just-posted message on "Embarrassing uberAlpha" for more information on this. > I also am intrigued by the Javascript code you have for web > templates -- I wonder if I can make use of that, too, > provided there is enough similarity of purpose. Yep - anything in the CVS (either the SF CVS with the Perl code, or the Drupal CVS) is Artistic or GPL licensed, so you can use it as needed. -- Morbus Iff ( united we're bland ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Morbus I. <mo...@di...> - 2004-11-29 15:06:09
|
This was sent this morning to the FRBR list. -------- Original Message -------- Subject: LibDB: Embarrassing UberAlpha Available Date: Mon, 29 Nov 2004 10:05:00 -0500 From: Morbus Iff <mo...@di...> To: fr...@in... With the sole intent of showing /something/, I've decided to let you all know about the latest with LibDB, my open sourced (MySQL and PHP) OPAC that is founded on the FRBR Final Report. Those with particularly acute memories may vaguely recall something about this very early in the year. First, LibDB is no longer a standalone application: it has not been integrated with the Drupal content management system (CMS). Drupal is also an open sourced (MySQL and PHP) application, and provides all the "other stuff" that any web site or service generally needs: content creation and document workflow, user management and access permissions, internationalization and translation, forums, aggregators, and blah blah blah. I felt that LibDB becoming an OPAC/CMS was more important than it being merely an OPAC. You can find more about Drupal, LibDB, and Why I Chose Drupal at the following URLs: http://www.drupal.org/ http://www.libdb.com/ http://www.libdb.com/why_drupal The new LibDB.com web site is also of interest: it is a full Drupal site with, more importantly, a very very very very early version of LibDB installed. This version does absolutely nothing /useful/, and it is with some embarrassment that I show it to you: I generally only like to unveil "WOW!" work, and not my in-progress stuff. To play with the LibDB uberAlpha: * sign up for an account at LibDB.com (which is running Drupal). * go to the "administer" menu and choose "libdb". In this very early version, there are only two goals: * represent "as little as possible" to get record manipulation working (this means that you'll only see G2 "Person" and no "Corporate Body", and only G1's "Manifestation" and no other G1 Entities). * get an administrative editing interface going, i.e., nothing that the public would ever want to browse through. It is very, very rough. I can't stress this enough. Out of a 100% project, I'm saying maybe barely 5% or 10% is finished. Of particular warning is that you can add a new record but you can't go in and edit it (this is one of the final things I've to do before moving on to the next big part: some sort of browsable public interface). The only things currently editable are all the individual parts: the Persons, Group 3 Entities, Other Data Types and so forth. To stay notified of LibDB updates: * create an account. * go to "my account" * choose "my notify settings" I'll still be posting news to this list, but it'll be more Milestone or Theory related, and not all the interim minor updates. The next major steps of the LibDB project include: * finish the administrative record editing interface. * re-examine the database schema (http://www.libdb.com/node/2) and update it according to all the comments since it's initial creation: FRBR super-types, handling dates, the variant table, etc., etc. * implement those database changes and update the editing code. * create some sort of browsing interface. -- Morbus Iff ( take your rosaries off my ovaries ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus -- Morbus Iff ( is this a cut out bath-poster Morbus, or what? ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Morbus I. <mo...@di...> - 2004-11-29 14:28:37
|
> Still, I don't know how a long string of numbers > generated by individual dbs helps though. Someone may want to poke around in the RDF/SW world for this one. They have very similar problems: if I, myself, give me a URI of dc:morbusiff, there is nothing stopping another person, unknown to be, calling me dc:morbus_iff in their application. How could the RDF/SW ever function with these statements that refer to the same thing, only with different IDs? The only relevant response I got back was a conversion router: feed it one ID, and get back a list of all relevant IDs that are equivalent, very similar to the OCLC's xISBN service: http://www.oclc.org/research/projects/xisbn/default.htm -- Morbus Iff ( evil is my sour flavor ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Bruce D'A. <bd...@fa...> - 2004-11-29 14:19:43
|
On Nov 29, 2004, at 9:06 AM, Morbus Iff wrote: > I've mentioned this before, but I don't think /any/ attempt to create > an ID that has embedded meaning will work, because any attempt to do > that in the past has failed or clashed (ISBNs, UPCs, etc.). I also > don't want IDs that are more than 60 characters long, as they're > inevitably loaded in a URL, and that makes the URL difficult to pass > around. This is a good point, particularly considering that my current stylesheets grab a complete bibliography collection with a single (very long!) url! Still, I don't know how a long string of numbers generated by individual dbs helps though. Documents have citations coded like: <citation><biblioref linkend="some-citation-id"/></citation> This is how they get coded in DocBook, it's how they will get coded in OpenOffice, and if I have my way, Word as well (you can embed the same citation schema that is going in OOo in WordML). So how do we make this work in an internet-enabled collaborative context? I got a link to this article about how CiteSeer handles this stuff: http://portal.acm.org/citation.cfm?id=1031171.1031275 Someone else posted a comment on the blog about a system that yields IDs like: Gilchrist:NAMS-36-9-1199 Doe:EW-99 The acronyms are for titles: in the first case for an academic journal, and in the second a book. The acronym is constructed by taking up to the first four words (other than "the", "a", "of" and so forth) of the title. I like this approach myself. In Endnote, BTW, there are two fields: one is the database ID, and the other is called "label." People who prefer the citekey approach typically use that for their citations instead of db ID. Bruce |
|
From: Morbus I. <mo...@di...> - 2004-11-29 14:06:39
|
> I just posted something on my blog about citation/record ids, which is > an issue that I think is going to become increasingly important. I've mentioned this before, but I don't think /any/ attempt to create an ID that has embedded meaning will work, because any attempt to do that in the past has failed or clashed (ISBNs, UPCs, etc.). I also don't want IDs that are more than 60 characters long, as they're inevitably loaded in a URL, and that makes the URL difficult to pass around. -- Morbus Iff ( you, me, eropuri? aawwwwwWWWw yYeahahhHHAhhh ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
