Hi Andrea,
the metadata/data model needs definitely adjusting, not only with
regards to bitstream related metadata, but also for other dspace objects.
It might be done according to the resourcepolicies, i.e. adding the
resource_type_id and changing item_id to resource_id in metadatavalue.
Thus you have the possibility to use all the metadata defined in the
registries for all the object types in DSpace.
sunny greetings
Claudia
Andrea Bollini schrieb:
> Hi,
> only a note: mime type and size are only two examples of bitstream's
> metadata. Many applications need to store more info about a specific
> bitstream (for example more granular metadata about mime type) specially
> for preservation purpose. So, why can't we extend item metadata model at
> bitstream, eg. why can't we allow any dspace installation to define new
> metadata for bitstream storing its in an new extarnal table
> BitstreamMetadataValue?
>
> Best wishes,
> Andrea
>
> At 23.27 12/11/2006, you wrote:
>> Ah, that makes sense. In that case it's fine to junk the item-level
>> metadata.
>>
>> Scott.
>>
>> Robert Tansley wrote:
>>
>>> Hi Scott,
>>>
>>> I'm suggesting that we use the format information present in the data
>>> model at the appropriate level (Bitstream--has_format-->Bitstream
>>> Format and Bitstream-->file_size) which can be exported by whatever
>>> crosswalks/packagers are needed. Hence the format information is
>>> already available in a far more useful form.
>>>
>>> What is the use case you're thinking of that would benefit from
>>> format.* being in the item-level DC metadata?
>>>
>>> Rob
>>>
>>> On 11/10/06, Scott Yeadon <scott.yeadon@...> wrote:
>>>
>>>> Hi Rob,
>>>>
>>>> Are you proposing that the format information is not set at all or
>>>> just set for the primary content?
>>>>
>>>> I know the way the formatting information is currently handled leaves
>>>> a bit to be desired but I think there probably needs to be some info
>>>> available at least for the primary bitstreams - especially since it's
>>>> not going to be long before interaction with format registries and
>>>> obsolence notification services is developed, and the ability to
>>>> provide format summary/reporting information (at least for the
>>>> primary bitstreams) will be needed for this.
>>>>
>>>> Icky as the current implementation is, from my point of view I'd
>>>> rather this were left in (or at least formatting info set for the
>>>> ORIGINAL bundle) until an alternative handling mechanism were in
>>>> place (e.g. Jhove/DRIOD MD extraction in a custom submission or plugin).
>>>>
>>>> Scott.
>>>>
>>>>
>>>> Date: Thu, 9 Nov 2006 11:06:39 -0500
>>>> From: "Robert Tansley" <roberttansley@...>
>>>> Subject: [Dspace-devel] Proposal: InstallItem not to set format.extent
>>>> and format.mimetype
>>>> To: "DSpace Developer List" <dspace-devel@...>
>>>> Message-ID:
>>>> <38d44e00611090806n7825361as76405c3669855566@...>
>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>>
>>>> IMO this is something silly that should never have been done anyway.
>>>>
>>>> InstallItem (the code that gets invoked whenever an Item passes
>>>> successfully through submission workflow or batch import) sets a value
>>>> for format.extent and format.mimetype in the Item's Dublin Core record
>>>> for every bitstream. This is silly because:
>>>>
>>>> - There's no way of corresponding which extent/mimetype corresponds to
>>>> which bitstream. (This is because it breaks the DC model -- it's
>>>> applying metadata about a contained object to the container).
>>>>
>>>> - No other parts of the code update these values should the bitstreams
>>>> be subsequently changed, added to or deleted.
>>>>
>>>> - The file size and MIME types are stored elsewhere in the DB, as well
>>>> as in the provenance DC field for the item.
>>>>
>>>> The result is that DSpace items the world over have lots of
>>>> format.extent and format.mimetype values which are quite possibly out
>>>> of date and impossible to tie to individual bitstreams.
>>>>
>>>> Any objections to me taking this out?
>>>>
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Dspace-devel mailing list
>> Dspace-devel@...
>> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
> *************************************************************
> Dott. Andrea Bollini
> Software Development AePIC - http://www.aepic.it
> (Academic e-Publishing Infrastructures)
> CILEA - Consorzio Interuniversitario per l'ICT
> Via R. Sanzio 4, I-20090 SEGRATE MI
> tel. +39 02 2699 5386
> *************************************************************
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Dspace-devel mailing list
> Dspace-devel@...
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
|