Re: [VuFind-Tech] Proposal: Record drivers to handle multiple formats

[Demian K. <dem...@vi...>]

Yes, this is definitely important.

Would it be worth starting to take inventory of the metadata formats that current VuFind users are hoping to work with in the future (i.e. real data sets that people want to import)?  If we know some real-life use cases, that might help us identify areas where disambiguation is necessary.

- Demian

> -----Original Message-----
> From: Ross Singer [mailto:ros...@gm...]
> Sent: Monday, August 03, 2009 3:49 PM
> To: Andrew Nagy
> Cc: Demian Katz; vuf...@li...
> Subject: Re: [VuFind-Tech] Proposal: Record drivers to handle multiple
> formats
> 
> Well, just to be clear, I don't think it matters how you identify the
> record formats internally (I meant to reply to this last week, but got
> sidetracked).
> 
> I just think it would be helpful if whatever VuFind's internal
> identifiers are correspond with some sort of universal identifier
> (and, again, I do not expect these to be the URIs in that Jangle
> registry - those just exist because Jangle needed _something_).
> 
> From the examples you included as "identifiers", the last three are
> already problematic just as weak identifiers:
> 
> mods, mets, dublincore
> 
> 1) MODS - this one is the least problematic, but versioning is
> potentially important here.  I think MODSv3 is probably sufficiently
> unambiguous in this case, though.
> 2) METS - by itself, METS is an _extremely_ weak identifier since it
> doesn't tell you anything about what's actually being transported
> /within/ the METS document (which, really, is the important part).
> It's these multi-format wrapper formats that are the most problematic.
> 3) DC is another strange case because it can be serialized in so many
> ways (RDF DC, OAI DC, SRU DC, etc.) -- simply from an xpath
> perspective, DC might need some disambiguation.
> 
> All I'm saying is that unless there's explicit agreement on the
> definition of a particular identifier, the semantics behind it tend to
> break down as people apply their own interpretation of it.  If it's
> tied to a defined vocabulary from the outset, it (theoretically) makes
> the variability of the data less likely.
> 
> -Ross.
> 
> On Mon, Aug 3, 2009 at 3:05 PM, Andrew Nagy<as...@gm...> wrote:
> > I don't commonly disagree with Ross - but I would have to agree with
> Demian
> > here.  It makes sense to capture the source metadata schema in the
> VuFInd
> > Solr index.  I propose the following to coincide with Ross's
> registry(which
> > could easily be crosswalked for compatability reasons to the standard
> > registry terms)
> >
> > marc
> > marcxml
> > mods
> > mets
> > dublincore
> > yada, yada, yada
> >
> > Andrew
> >
> > On Thu, Jul 30, 2009 at 12:58 PM, Demian Katz
> <dem...@vi...>
> > wrote:
> >>
> >> > For the last bullet point there, it would be nice if this jibed
> >> > harmoniously with how Jangle defines these identifiers (regardless
> of
> >> > whether or not there's still any interest in Jangle support in
> >> > VuFind).
> >>
> >> I assume this is the format registry you were referring to:
> >>
> >>        http://www.jangle.org/drupal/vocab/formats
> >>
> >> For purely practical reasons, I don't think it would make sense to
> use
> >> these proposed strings (URIs and/or mime-types) as VuFind's internal
> >> representation of format identifiers.  I say this mainly because the
> most
> >> convenient naming would be to use something that would serve as both
> a valid
> >> filename and PHP class name, so that VuFind could dynamically
> include and
> >> instantiate the appropriate driver module based on the name of the
> file
> >> format being used.
> >>
> >> If Jangle compatibility is necessary, though (and I'm new to this
> issue,
> >> so apologies for missing most of the relevant background here), one
> simple
> >> solution would be to include a getJangleFormat() method as part of
> the
> >> driver API specification so that you could query any record driver
> object
> >> for its detailed Jangle-compatible format name.  That leads to
> questions
> >> about what to use for proprietary formats, etc., but it seems like a
> >> possible starting point.
> >>
> >> - Demian
> >>
> >>
> >> --------------------------------------------------------------------
> ----------
> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> >> 30-Day
> >> trial. Simplify your report design, integration and deployment - and
> focus
> >> on
> >> what you do best, core application coding. Discover what's new with
> >> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >> _______________________________________________
> >> Vufind-tech mailing list
> >> Vuf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/vufind-tech
> >
> >