It appeared very recently (depending on your timeframe) -- but that version
is absolutely necessary because the javascript support in 3.0 couldn't
support what I needed to do. And I had no access to cgi at the time I wrote
it, so server side action that might have accommodated Mosaic aficionados
was out of the question...

kyle


On Mon, Sep 30, 2013 at 2:08 PM, Roy Tennant <[log in to unmask]> wrote:

> Netscape 4.0 is out? Gosh, but it sure is hard to keep up!
> Roy
>
>
> On Mon, Sep 30, 2013 at 2:06 PM, Kyle Banerjee <[log in to unmask]
> >wrote:
>
> > If all people need is to look up MARC tags, there is also the Cataloging
> > Calculator http://calculate.alptown.com/  Unless you want to want to
> feel
> > totally disgusted, avoid looking source code as it was my first
> javascript
> > program which was cobbled together in a day (i.e. it is garbage) and
> hasn't
> > been gone through a substantial revision since 1997. The good news is
> that
> > if you're still on Netscape 4.0, it should work fine...
> >
> > kyle
> >
> >
> > On Mon, Sep 30, 2013 at 1:56 PM, Roy Tennant <[log in to unmask]>
> wrote:
> >
> > > As seen on Twitter, OCLC also has our version of MARC documentation
> here:
> > >
> > > <http://www.oclc.org/bibformats/en.html>
> > >
> > > It's mostly exactly the same except for the places where we have
> inserted
> > > small but effective messages that "RESISTANCE IS FUTILE, YOU WILL BE
> > > ASSIMILATED".
> > > Roy
> > >
> > >
> > > On Mon, Sep 30, 2013 at 1:31 PM, Becky Yoose <[log in to unmask]>
> wrote:
> > >
> > > > FYI - this also means that there's a very good chance that the MARC
> > > > standards site [1] and the Source Codes site [2] will be down as
> well.
> > I
> > > > don't know if there are any mirror sites out there for these pages.
> > > >
> > > > [1] http://www.loc.gov/marc/
> > > > [2] http://www.loc.gov/standards/sourcelist/index.html
> > > >
> > > > Thanks,
> > > > Becky, about to be (forcefully) departed with her standards
> > documentation
> > > >
> > > >
> > > > On Mon, Sep 30, 2013 at 11:39 AM, Jodi Schneider <
> [log in to unmask]
> > > > >wrote:
> > > >
> > > > > Interesting -- thanks, Birkin -- and tell us what you think when
> you
> > > get
> > > > it
> > > > > implemented!
> > > > >
> > > > > :) -Jodi
> > > > >
> > > > >
> > > > > On Mon, Sep 30, 2013 at 5:19 PM, Birkin Diana <
> > [log in to unmask]
> > > > > >wrote:
> > > > >
> > > > > > > ...you'd want to create a caching service...
> > > > > >
> > > > > >
> > > > > > One solution for a relevant particular problem (not full-blown
> > > > > linked-data
> > > > > > caching):
> > > > > >
> > > > > > http://en.wikipedia.org/wiki/XML_Catalog
> > > > > >
> > > > > > excerpt: "However, if they are absolute URLs, they only work when
> > > your
> > > > > > network can reach them. Relying on remote resources makes XML
> > > > processing
> > > > > > susceptible to both planned and unplanned network downtime."
> > > > > >
> > > > > > We'd heard about this a while ago, but, Jodi, you and David
> Riordan
> > > and
> > > > > > Congress have caused a temporary retreat from normal sprint-work
> > here
> > > > at
> > > > > > Brown today to investigate implementing this!  :/
> > > > > >
> > > > > > The particular problem that would affect us: if your processing
> > tool
> > > > > > checks, say, an loc.gov mods namespace url, that processing will
> > > fail
> > > > if
> > > > > > the loc.gov url isn't available, unless you've implemented xml
> > > > catalog,
> > > > > > which is a formal way to locally resolve such external
> references.
> > > > > >
> > > > > > -b
> > > > > > ---
> > > > > > Birkin James Diana
> > > > > > Programmer, Digital Technologies
> > > > > > Brown University Library
> > > > > > [log in to unmask]
> > > > > >
> > > > > >
> > > > > > On Sep 30, 2013, at 7:15 AM, Uldis Bojars <[log in to unmask]>
> > > wrote:
> > > > > >
> > > > > > > What are best practices for preventing problems in cases like
> > this
> > > > when
> > > > > > an
> > > > > > > important Linked Data service may go offline?
> > > > > > >
> > > > > > > --- originally this was a reply to Jodi which she suggested to
> > post
> > > > on
> > > > > > the
> > > > > > > list too ---
> > > > > > >
> > > > > > > A safe [pessimistic?] approach would be to say "we don't trust
> > > > > > [reliability
> > > > > > > of] linked data on the Web as services can and will go down"
> and
> > to
> > > > > cache
> > > > > > > everything.
> > > > > > >
> > > > > > > In that case you'd want to create a caching service that would
> > keep
> > > > > > updated
> > > > > > > copies of all important Linked Data sources and a fall-back
> > > strategy
> > > > > for
> > > > > > > switching to this caching service when needed. Like
> > archive.orgfor
> > > > > > Linked
> > > > > > > Data.
> > > > > > >
> > > > > > > Some semantic web search engines might already have subsets of
> > > Linked
> > > > > > Data
> > > > > > > web cached, but not sure how much they cover (e.g., if they
> have
> > > all
> > > > of
> > > > > > LoC
> > > > > > > data, up-to-date).
> > > > > > >
> > > > > > > If one were to create such a service how to best update it,
> > > > considering
> > > > > > > you'd be requesting *all* Linked Data URIs from each source? An
> > > > > efficient
> > > > > > > approach would be to regularly load RDF dumps for every major
> > > source
> > > > if
> > > > > > > available (e.g., LoC says - here's a full dump of all our RDF
> > data
> > > > ...
> > > > > > and
> > > > > > > a .torrent too).
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > Uldis
> > > > > > >
> > > > > > >
> > > > > > > On 29 September 2013 12:33, Jodi Schneider <
> [log in to unmask]
> > >
> > > > > wrote:
> > > > > > >
> > > > > > >> Any best practices for caching authorities/vocabs to suggest
> for
> > > > this
> > > > > > >> thread on the Code4Lib list?
> > > > > > >>
> > > > > > >> Linked Data authorities & vocabularies at Library of Congress
> (
> > > > > > id.loc.gov)
> > > > > > >> are going to be affected by the website shutdown -- because of
> > > lack
> > > > of
> > > > > > >> government funds.
> > > > > > >>
> > > > > > >> -Jodi
> > > > > >
> > > > >
> > > >
> > >
> >
>