Re: [VuFind-Tech] Using a defined format for display instead of MARC

[Andrew N. <as...@gm...>]

Yes - I think this is the best approach.  We should have a field that
defines the record format as was suggested.  Right now we only have a marc
importer (solrmarc) but other possibilities exist: an oai importer, a mets
importer and mods importer and so on.

Each importer is responsible for reporting the record format

Since each record type will use the same solr schema - the records service
will work for each.  For more detailed displays (staff view, etc) the core
record class could decide which functionality to provide based on the record
format.

This idea has been on my plate for a very long time - I've been talking
about integrating something like the homegrown digital library system at
villanova into VuFind for display of "digital objects" and have other
interfaces for different types of record formats.  It would be nice to have
an openurl resolved built into VuFind for the journal record display that
shows all of the different databases to access the specific record.

On the VuFind document wiki we have a place for requirements.  It might be
nice if someone has some interest to create a requirement for this feature
on the wiki so that we can all coordinate our ideas.

Andrew

On Mon, Jun 8, 2009 at 2:38 PM, Chris Delis <ce...@ui...> wrote:

>
> On 6/8/09 12:00 PM, "Ross Singer" <ros...@gm...> wrote:
>
> > On Mon, Jun 8, 2009 at 8:40 AM, Chris Delis<ce...@ui...>
> wrote:
> >> Bingo.  I think the correct answer is to allow VUFind to handle multiple
> >> record types, i.e., object-oriented / polymorphic.
> >
> > This is, generally speaking, how Blacklight works.  You can store
>
> Thanks, Ross.  I was thinking of Blacklight in my reply, but didn't know
> enough about it to say anything substantive about it (I only saw a demo of
> it a while back).
>
> Chris
>
>
> > anything in Solr, you then indicate what "type" of data the document
> > contains and then write an appropriate class for it.
> >
> > So there's basically two approaches:
> >
> > 1) A 'universal' bibliographic data format that other records types
> > (MARC, MODS, DC, MAB2, PICA+, EAD) can be mapped to
> > 2) A means to 'type' documents and provide different search maps and
> > templates accordingly.
> >
> > There are pros and cons to each.
> >
> > -Ross.
> >
> >>
> >> Chris
> >>
> >>
> >> On 6/8/09 7:03 AM, "Tuan Nguyen" <tu...@yo...> wrote:
> >>
> >>> How about adding a field to schema.xml say, recordformat, (stored but
> >> not
> >>> index) to indicate what format the fullrecord field is? Then, we
> >> can have
> >>> Record.php pick different template for the details view based
> >> on the
> >>> recordformat.
> >>
> >> On Jun 8, 2009, at 7:24 AM, Jakob Voss <jak...@gb...>
> >>> wrote:
> >>
> >>> Eric Lease Morgan wrote:
> >>>
> >>>>> I like vufind very much, imported a
> >>> few thousand MARC21 records
> >>>>> successfully and want to import records from
> >>> other data sources as
> >>>>> well.
> >>>
> >>> [...]
> >>>
> >>>> It seems to me that VUFind was
> >>> designed around MARC records. While I
> >>>> have very seriously considered
> >>> indexing stuff directly to the
> >>>> underlying Solr index, I have also seen that
> >>> many of the displays
> >>>> pull
> >>>> from MARC-ish fields. Many of the
> >>> specialized views (Holdings,
> >>>> Description, and Staff) come to mind.
> >>> Converting your metadata to
> >>>> MARC
> >>>> (ick) and stuffing the result into
> >>> VUFind seems like a viable
> >>>> solution. Not necessarily ideal but
> >>> functional.
> >>>
> >>> As long as VuFind is stuck to MARC format, it will remain a
> >>> dead end.
> >>> For our applications we could use PICA+ format but I think it's
> >>> the
> >>> same
> >>> garbage. A simple, general tree structure like JSON should be
> >>> easy
> >>> enough to work with - and it can be understood by non-library nerds.
> >>>
> >>> No
> >>> subfields, indicators, controlfields and such - just fields and
> >>>
> >>> (single
> >>> or multiple) values.
> >>>
> >>> For most cases a flat structure of
> >>> unordered fields with repeatable,
> >>> sorted values should be enough:
> >>>
> >>> <WS>
> >>> ::= %x20 | %x09 | %x0A | %x0D
> >>>
> >>> <RECORD> ::= <WS>* '{' <MEMBER>+ '}'
> >>> <WS>*
> >>>
> >>> <MEMBER> ::= <WS>* <FIELD> <WS>* ':' <WS>* ( <LIST> | <VALUE> )
> >>> <WS>*
> >>>
> >>> <LIST> ::= '[' <WS>* <VALUE> ( <SEPARATOR> <VALUE> )* <WS>* ']'
> >>>
> >>>
> >>> <SEPARATOR> ::= <WS>* ',' <WS>*
> >>>
> >>> <VALUE> ::= '"' <escaped-unicode-string>
> >>> '"'
> >>>
> >>> <FIELD> ::= '"' <escaped-unicode-string> '"'
> >>>
> >>> FIELDs must be unique
> >>> per record and their order is irrelevant. Lists
> >>> must not be empty - just
> >>> omit the field to become empty/undefined.
> >>>
> >>> This is a pure subset of JSON.
> >>> If you like you can define a similar
> >>> structure in XML, YAML or even RDF. If
> >>> should be good practise to use
> >>> URIs as fields but you can also use plain
> >>> strings. Your display
> >>> component can pick and order the fields it knows. On
> >>> worst case just
> >>> display all fields and their values in random order.
> >>>
> >>> If
> >>> needed we could use nested structures (full JSON) or more specific
> >>> formats
> >>> defined by XML Schema, YAML Schema, RDFS, OWLS whatever.
> >>> Unless
> >>> there is
> >>> no formal schema of MARC[*] or whatever format you should
> >>> better use a
> >>> simpler format.
> >>>
> >>> Greetings,
> >>> Jakob
> >>>
> >>> [*] There is no formal MARC schema.
> >>> There is an XML Schema of MARCXML
> >>> but this schema only describes the general
> >>> structure of fields, but
> >>> not
> >>> *which* fields can be / must be
> >>> present.
> >>>
> >>> --
> >>> Jakob Voß <jak...@gb...>, skype: nichtich
> >>>
> >>> Verbundzentrale des GBV (VZG) / Common Library Network
> >>> Platz der Goettinger
> >>> Sieben 1, 37073 Göttingen, Germany
> >>> +49 (0)551 39-10242,
> >>> http://www.gbv.de
> >>>
> >>> ---
> >>> ---
> >>> ---
> >>>
> >>> ---------------------------------------------------------------------
> >>>
> >>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> >>>
> >>> looking to deploy the next generation of Solaris that includes the
> >>>
> >>> latest
> >>> innovations from Sun and the OpenSource community. Download a copy
> >>> and
> >>> enjoy capabilities such as Networking, Storage and Virtualization.
> >>> Go
> >>> to: http://p.sf.net/sfu/opensolaris-get
> >>>
> >>> _______________________________________________
> >>> Vufind-tech mailing list
> >>>
> >>> Vuf...@li...
> >>>
> >>> https://lists.sourceforge.net/lists/listinfo/vufind-tech
> >>>
> >>
> >> ------------------
> >>> ------------------------------------------------------------
> >> OpenSolaris
> >>> 2009.06 is a cutting edge operating system for enterprises
> >> looking to deploy
> >>> the next generation of Solaris that includes the latest
> >> innovations from Sun
> >>> and the OpenSource community. Download a copy and
> >> enjoy capabilities such as
> >>> Networking, Storage and Virtualization.
> >> Go to:
> >>> http://p.sf.net/sfu/opensolaris-get
> >> __________________________________________
> >>> _____
> >> Vufind-tech mailing
> >>> list
> >> Vuf...@li...
> >> https://lists.sourceforge.net/lists/lis
> >>> tinfo/vufind-tech
> >>
> >>
> >>
> >>
>
> ----------------------------------------------------------------------------->>
> -
> >> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> >> looking to deploy the next generation of Solaris that includes the
> latest
> >> innovations from Sun and the OpenSource community. Download a copy and
> >> enjoy capabilities such as Networking, Storage and Virtualization.
> >> Go to: http://p.sf.net/sfu/opensolaris-get
> >> _______________________________________________
> >> Vufind-tech mailing list
> >> Vuf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/vufind-tech
> >>
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Vufind-tech mailing list
> Vuf...@li...
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>