On Apr 6, 2006, at 5:49 AM, Matthias Steffens wrote:
It should not be an exclusive choice whether a user uses one mechanism
or the other, BOTH mechansims should be provided at the same time (if
available). This will highly increase the chance that the bibliographic
database will find the best/desired record.
I think you're worrying too much about this. Let me explain with
examples.
Let's imagine a document where only two article citations are added:
article X with a DOI, and article Y without. Your citation references
looks like this internally:
<cite:biblioref key="info:doi/343243254456"/>
<cite:biblioref key="user:msteffens:doe99/>
[note: actually, ideally for a web app, you'd have
"http://refbase.net/msteffens/doe99";]
The associated bibliographic records are embedded in the file wrapper,
each identified with those ids.
Two scenarios:
Scenario 1: single author, single database (you)
================================================
You have some config option that says your preferred database. If your
embedded bibliography list needs to be regenerated, it asks RefBase for
those records (again).
There is no difficulty at all because the database is the same.
Scenario 2: multiple authors, multiple databases
================================================
User A adds the citations, and user B receives that document with the
embedded data.
Let's say user B's database, to make things complicated, contains
reference X, but did not include the DOI when storing it. Conversely,
they do have the DOI for reference Y.
In other words, if user B had added the same citations, the pointers
would look like this:
<cite:biblioref key="user:b:smith04"/>
<cite:biblioref key="info:doi/12345464565"/>
At this point, it doesn't matter what id schema you use, because you
have a conflict. You'd have the SAME conflict if both users used
user-specific labels for ids. OOoBib, in looking at user B's database,
cannot find either of these records just based on the id.
However, because the metadata is embedded in the file wrapper, it's
possible to resolve this fairly easily.
* lookup the corresponding references based on embedded metadata
(title, etc.)
* when found, offer user choice to update local and embedded data; if
yes:
- "user:b:smith04" is added to local record as a possible id for item
X
- "info:doi/12345464565"is added to local record as a possible id for
item Y
- citations are updated so that both use the universal id, you end up
with:
<cite:biblioref key="info:doi/343243254456"/>
<cite:biblioref key="info:doi/12345464565"/>
when user A gets the document back, same normalization process happens,
so that both databases contain the equivalent identifiers.
The document is now portable. If you send this to a publisher, they can
extract the citations and make sense of them.
In any case, the business of identifying is mostly orthogonal to proper
resolution. Precisely because we embed the bib metadata, the only
thing that REALLY matters is whether the citation ids match an
equivalent bib record.
This is why I say, BTW, it makes no sense to use user-based keys by
default. If you have a DOI or ISBN, use it; you lose nothing. By
specifying your preferred database(s), and always embedding the bib
data in the wrapper, you're insured of getting the correct records and
of having the logic there to resolve against different databases.
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
