Hello
I have a branch, but it is still in my private repository. I will push it to
public hopefully today.
(I am struggling with weird problems with regression tests... was
BibRecDocsTest.test_BibRecDocs ever passing? For my taste the test requests
incorrect file sizes ... and indeed it fails on my machine)
Indeed a type might be important for the connection between record and
document. In Your example though, the object is plot in both cases.
In one, also has the function of being part of a bigger record and in the
second case, the record describes a plot itself, so there is a sense in having
type stored in two places - in BibDoc and in the relation to a record as it
means something slightly different.
Still, there is a problem, how BibUpload should deal with non-record data and
with relations between documents.
The document identifier is internal to Invenio and should not be passed inside
"MARC" FFT (or some similar field). Addressing by recordId/Name seems not to be
universal enough if we generalise the BibDoc file.
Piotr
________________________________________
From: Samuele Kaplun
Sent: 06 June 2011 14:18
To: Piotr Praczyk
Cc: inspire-dev
Subject: Re: [inspire-dev] Limitations with having standalone BibDocs
Hi Piotr,
Il giorno lun, 06/06/2011 alle 11.57 +0000, Piotr Praczyk ha scritto:
> Some time ago I was talking with Tibor about a possibility of having
> standalone BibDocs.
I think it might be better to move this discussion on
<project-cdsware-developer> mailing list as your issue are really
touching one of the core parts of Invenio.
> Also Salvatore said that they could be very useful in the near future
> for storing different pieces of data.
Sure they are.
> While going through the source code of bibdocfile.py, I discovered two
> things that are not exactly as they were described to be.
> In particular, the possibility of having a BibDoc not attached to any
> bibrecord is explicitly blocked in the source code of BibDoc class.
>
> (The constructor tries to retrieve the identifier of the record to
> which the document is related and the case of failure, throws one of
> exceptions:
> raise InvenioWebSubmitFileError, "The docid %s associated with
> docid %s is not associated with any record" % (main_docid, docid)
> raise InvenioWebSubmitFileError, "The docid %s is not associated to
> any recid or other docid" % docid
> )
Indeed. On the other hand, since the very link is stored in one simple
table this limitation should be easy to remove. However there are
several assumptions made in several part of Invenio about this link,
namely in the bibdocfile CLI, and as you mention below in BibUpload too.
Another enhancement I was always thinking to add, is the possibilities
to have one bibdoc attached to several records (in the end the
bibrec_bibdoc table allows for a many-to-many connection).
> Moreover, BibDoc does not really hold a type.
> The type of document is a property of the link between record and the
> document.
> Should we modify this ? This would have some deeper implications for
> BibUpload as we would have to have a possibility of uploading data not
> being associated with a record.
This is also why I would suggest to talk about this in the wider mailing
list. Today the doctype is not such a used property, although it is used
more and more in INSPIRE. On the other hand moving it from being a
property of the connection between a bibrec and a bibdoc, to be a
property of a single bibdoc, would imply that a bibdoc is intrinsically
of a given type, regardless of its context. That means that it would no
longer be possible, in case we allow to have a bibdoc to be pointed by
many records, to sports different types.
A "Plot" within record A can in principle be thought as a "Main" in
record B.
This open a big discussion about support for compound digital objects,
that, since you propose to extend bibdocfile, it would be great to fully
address in the best manner (e.g. taking in consideration METS, and
OAI-ORE use cases).
Shall we build a task force on the topic?
Cheers!
Sam
P.s. on an other subject, we are accumulating use-cases for your
extended MoreInfoBibDocFile, to be able to attach properties either at
the level of BibDocFile or at the level of the BibDoc. Have by chance
already started working on it and do you have a branch with some draft
to play with?
--
Samuele Kaplun
Invenio Developer ** <http://invenio-software.org/>
