Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Library ontologies are like ontologies generally: there is no "right" answer, all aswers create problems, and one size does not fit all. With all such intractable problems, I say that no-one should be particularly upset about just making up a solution of their own. If it has some sort of problems, don't worry, you'll discover that for yourself soon enough.

    A problem being "intractable" doesn't mean that it can't get easier to deal with, once one has more experience. To the contrary, I think experience is the only way -- so try it and see!

    I can't promise that experience actually produces massively better solutions -- but I'd be happy just knowing that the solutions come faster and easier, and possibly that experience at least gives greater insight (whatever that means) into past attempts at solutions.

    Now reread what I said, and instead of reading it as being about library cataloguing, read it as being about programming.

    • I agree with this...there is definitely not a "right" answer. However, one thing to bear in mind is that the MARC format has been around alot longer than XML and the Web, and it is used as an interchange format by libraries around the world. The price you pay for developing your own solution is in interoperability. But if that is not a price, then it's not a big deal.

      You may want to take a look at the Dublin Core [dublincore.org], which was largely developed because MARC was complex and not very well suited to the needs o