LISTSERV mailing list manager LISTSERV 16.5

Help for CODE4LIB Archives


CODE4LIB Archives

CODE4LIB Archives


CODE4LIB@LISTS.CLIR.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CODE4LIB Home

CODE4LIB Home

CODE4LIB  November 2005

CODE4LIB November 2005

Subject:

File system abstraction

From:

Alexander Johannesen <[log in to unmask]>

Reply-To:

Code for Libraries <[log in to unmask]>

Date:

Wed, 9 Nov 2005 08:41:00 +1100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (147 lines)

[sorry if this is a repost ; mail problems! ]



Hi Guys,

The background for the filesystem-based structure is what's come out
of me working for the National Library of Australia, although it has
nothing library specific about it. Basically, there are pre- and post
processes we do with our data, such as converting to and fro various
formats, analysing them, indexing, filtering and so forth, and quite
often, because all or most of our tools exsist outside of databases,
the filesystem is the place to be. (I've written some more rationale
for the use of filesystems instead of RDBMS's, but that sort of
formality is a banality in a forum such as this ... :)


********

The gist of it is three main directories, where 'apps' and 'libs' are
a shared space for various tools, applications and reusable libraries,
and a 'data' directory is a shared space with a special meaning ;

  /apps
  /libs
  /data

The data directory can contain as many subdirectories as you want,
with the constraint that each of them is a data-set, so for example
for a data-set that consist of records of childrens literature, it
might look like ;

  /data/childrenslit

Also in the data directory is a configuration file called config.xml,
and you register your apps, libs and data-sets in it, although only
the data-set registration is mandatory ;

<config>
  <!-- Register your apps here if you like ... -->
  <apps />
  <!-- Register your libs here if you like ... -->
  <libs />
  <!-- You must register your data-sets here -->
  <data>
     <data-set id="childrenslit">
        <with-records schema="marc21" read-access="true"
           write-access="false" update-access="false" />
     </data-set>
  </data>
  <!-- Register your supported schemata here -->
  <schemata>
     <schema id="marc" extension="bin" />
     <schema id="marc21" namespace="http://..." extension="xml" />
     <schema id="mods" namespace="http://..." extension="xml" />
     <schema id="xobis" namespace="http://..." extension="xml" />
     <schema id="rss2" namespace="http://..." extension="xml;rss;rdf" />
     <schema id="foap" namespace="http://..." extension="rdf" />
  </schemata>
</config>

Each data-set's id is the name of the directory it resides in, and you
specify what schemas you can expect to find in that structure ;

        <with-records schema="marc" read-access="true"
           write-access="true" />
        <with-records schema="marc21" read-access="true"
           write-access="false" update-access="false" />

The example above would specify a data-set where we can read and write
MARC records, but only read MARC 21 XML, a typical MARC to MARC XML
conversion. We can also see that for each record we can expect one
MARC file and one MARC XML file. If there is discrepencies, we know
what tools to call to do a conversion if a new record has been popped
into the structure. Any tool that wants to work on this data-set know
what parts of the data-set they can read, write and update. (I'm sure
better concurrency information could be thought of)

Next is the structure of the data-set directory itself. If we go back
to our previous example ;

 /childrenslit

The tree-structured dirindex is required from this directory and three
levels deep. Each record is in the format [id].[schema].[extension].
An example for a MARC XML record with id '676732a' ;

 /childrenslit/a/a2/a23/676732a.marc21.xml

Notice the reverse order for the id directory structure; most id's are
rightly bound to uniqueness / traffic, so just a pragmatic choice.
There is no requirement to create a tree-structured dirindex for all
possible combinations, only those who will be filled with actual
records. If a directory becomes empty at a later stage, that directory
can also be deleted.

(There is here also the possibility to create a file index definition
file, but I'll hold this off until needed; file structure traversing
is more a configuration issue than a technical one)

How it is supposed to work
--------------------------------

I can have different apps that looks at the same data-set to do
various things to it. For example, here are two apps that use the same
data-set ;

    <application id="my_app">
       <description>Converts MARC to MARC XML</description>
       <uses data-set="childrenslit">
          <reactor schema-idref="marc" test="new;update" />
       </uses>
    </application>
    <application id="my_other_app">
       <description>Indexes MARC XML</description>
       <uses data-set="childrenslit">
          <reactor schema-idref="marc21" test="new;update;delete" />
       </uses>
    </application>

Both applications knows from the config.xml file who does what, and we
can write reactors to data added, updated or deleted in a given
schema.

The idea from here is that we simply can exchange apps and libs and
point to what data-set we want them to work with. If an app has
support for a few good schemas, it would be a simple matter of
plonking it it, update config.xml, and then run it.

By this I could share with you for example the XPF framework to create
a Topic Maps website from any data-set (MARX XML, Topic Maps, RDF,
RSS, DocBook and a few other schemata), the Phonto tool (automatic
ontology extraction and analysis tool) and a host of XSLT libraries
for various conversions. Imagine next the creation of lexical parsers,
AI tools, data-set to SemWeb bridges, and so forth, easily shared. I
have some data-sets, you have others, and often sharing these are
restricted, so let's share tools that read the same structures, on the
path to world domination.


Anyways, that's the basic idea, in no ways exhaustive terms. Any thoughts?


--
"Ultimately, all things are known because you want to believe you know."
                                                         - Frank Herbert
__ http://shelter.nu/ __________________________________________________

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003

ATOM RSS1 RSS2



LISTS.CLIR.ORG

CataList Email List Search Powered by the LISTSERV Email List Manager