(with apologies for cross-posting)
The Open Discovery Initiative (ODI), a working group of the National
Information Standards Organization (NISO), has been formed to develop a
Recommended Practice related to the index-based discovery services for
libraries. ODI aims to investigate and improve
I agree entirely that these would need to be a collection of triples with its
own set of attributes/metadata describing the collection. Basically a record
with triples as the data elements.
But I see a bigger problem with the direction this thread has taken so far. The
use of versions has been
We cried our eyes out in 1976 when this first came to our attention at the BL.
Even more crying when we couldn't get rid of it in the MARC-I to MARC-II
conversion (well before MARC21 was even a twinkle) - a lot of tears are
gathering somewhere.
Peter
-Original Message-
From: Code
.
Graham
On 03/30/12 01:09, Peter Noerr wrote:
Hi Graham,
What we do in our federated search system, and have been doing for some
few years, is basically
give the designer a choice of what options the user gets for de-duped
records.
Firstly de-duping can be of a number of levels
Hi Graham,
What we do in our federated search system, and have been doing for some few
years, is basically give the designer a choice of what options the user gets
for de-duped records.
Firstly de-duping can be of a number of levels of sophistication, and a many of
them lead to the situation
There was a system developed back in the '80s which stored its records
internally in a direct Entity-Relationship database and allowed inter-record
linking and a rather hyperlink-like data structure. BUT... that was all
internal. It allowed some very nice OPAC features and possibly easier
This post veers nearer to something I was going to add as an FYI, so here
goes...
FYI: NISO has recently started a working group to study best practices for
discovery services. The ODI (=Open Discovery Initiative) working group is
hoping to look at exactly this issue (how should a content
Crazy variation number 3. Have two tracks which are identical, but time shifted
by half a day (or some other convenient unit). The presenters talk twice on the
same day - in the morning for track A and the afternoon for track B. That way
there is no speaker gulag, no time over-run (though,
+1
Peter Noerr
MuseGlobal
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen
Schneider
Sent: Thursday, December 22, 2011 11:11 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Obvious answer to registration limitations
Being no longer in Europe, I had completely missed the currently hot potato
definition of EMU. But it had a nice feel to it sigh
I agree with Karen below that a record seems more bounded and static, whereas a
description varies according to need. And that is the distinction I was trying
to get
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Richard Wallis
Sent: Tuesday, December 13, 2011 3:16 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Namespace management, was Models of MARC in RDF
On 13 December 2011 22:17, Peter
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Karen
Coyle
Sent: Sunday, December 11, 2011 3:47 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Namespace management, was Models of MARC in RDF
Quoting Richard Wallis
See historical comment in text below. But, to look forward -
It seems to me that we should be able to design a model with graceful
degradation from full MARC data element set (vocabulary if you insist) to a
core set which allows systems to fill in what they have and, on the receiving
end,
This looks really colorful, but how does it aid searching, or browsing?
The pie chart is useful for a collections development librarian to see how the
collection is distributed across broad subject areas.
How does it help me, a user, searching for books on Dentistry (yes they are
there, all
Numerous comments from today's posts.
As to Jonathan on complexity, resources and we've got it working. Indeed you
have and it is a cool looking UI and functionality behind it. I did not mean to
imply that you had not got a working system, or that anyone else could not do
it (see Dan's
Just curious: - what do you mean by Some way to avoid the site-scrapers who
populate the troubleshooting
pages. (last sentence below)?
I presume you are wishing to avoid the trouble shooting sites which consist
of nothing more than pages copied from other sites, and look only at the prime
, from
multiple Sources (it is messy - believe me).
I would be very happy to see such a protocol (and have it implemented), and if
Jakub implemented browser code to handle that end, then the users could benefit.
Peter
Peter Noerr
CTO. MuseGlobal
www.museglobal.com
-Original Message
in, and the user will never even get there. And if the
majority of users are only looking at results from one resource... why
do a broadcast multi-server search in the first place?
Peter Noerr wrote:
However things are a bit different now... At the risk of opening the
debate once more and lots
of these cases, the subsequent results will
be
several pages in, and the user will never even get there. And if the
majority of users are only looking at results from one resource... why
do a broadcast multi-server search in the first place?
Peter Noerr wrote:
However things are a bit
For our fed search service we very much echo Jonathan's real-time
requirements/use case (we don't build indexes, so bulk download is not of
interest):
access - real-time query (purpose - to enhance data about items found by other
means)
query - by standard IDs (generally this is known item
For our purposes (federated search) it would be most useful to have as many of
the available links (OL or other) as possible, and as much information about
the link as possible. Obvious structural stuff like the type of identifier,
but also the nature of the linked object (as you suggest full
I will just add (again) to the request for all links. As Jonathan says the
client can then decide what to show, how to group them, and so on.
I had rather sloppily elided things like format of full text into my
structural information about the link.
And second the request that some simple
strong workshop format.
Peter Noerr
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
Frumkin, Jeremy
Sent: Thursday, June 04, 2009 08:51
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] code4lib / elag2010
Hi Nicolas -
I think what
I am pleased to disagree to various levels of 'strongly (if we can agree on a
definition for it :-).
Ross earlier gave a sample of a crossw3alk' for my MARC problem. What he
supplied
-snip
We could have something like:
http://purl.org/DataFormat/marcxml
. skos:prefLabel MARC21 XML .
.
at 3:41 PM, Peter Noerr pno...@museglobal.com wrote:
I am pleased to disagree to various levels of 'strongly (if we can agree
on a definition for it :-).
Ross earlier gave a sample of a crossw3alk' for my MARC problem. What he
supplied
-snip
We could have something like:
http
? Because anyone can produce
any identifier they like, we have decided that the unification of them has to
be kept internal where we at least have control of the unifications, even if
they change pretty frequently.
Peter
Dr Peter Noerr
CTO, MuseGlobal, Inc.
+1 415 896 6873 (office)
+1 415 793
on a Source
by Source basis. Admins can allow users to have this strict/relaxed switch or
not. And users can apply it or not. For both the majority case is not (i.e.
relaxed is used).
Peter
Dr Peter Noerr
CTO, MuseGlobal, Inc.
+1 415 896 6873 (office)
+1 415 793 6547 (mobile)
www.museglobal.com
to the original
documents (i.e. at the native Source).
I can't imagine this has done more than confirm that there is no agreed
terminology - which we sort of all knew. So we just do a lot of explaining -
with pictures - to people.
Peter Noerr
Dr Peter Noerr
CTO, MuseGlobal, Inc.
+1 415 896 6873
.
Peter Noerr
MuseGlobal
(ex British Library - founder member of ELAG)
From: Code for Libraries on behalf of Edward M. Corrado
Sent: Sat 2009-01-24 17:46
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Dutch Code4Lib
I really don't know much about ELAG
Hi Steve,
Thanks for a full reply.
We actually do combine date within enterprises, including from their ILS
and subscription Sources (article databases), and internal repositories.
Of course we claim we do it well - and I think we do. A library
background will enable you to face almost any shape
? It obviously has taken Steve and his colleagues a lot of
hard work to produce a nice looking system (except for all those big
black bits on the screen!) and it obviously takes maintenance (it is
'fragile') Do you think it was/is worth it and if so why?
Peter Noerr
-Original Message-
From
31 matches
Mail list logo
