Samuele,
I recently created a SWORD V2 extension for depositing OER in Connexions
and other XML based remixable repositories
(OERPub<https://docs.google.com/document/d/1hMvUA3oevZhUG2vo3IEiHCr-yMNCFXDambzalOM-XKU/edit?hl=en_US#heading=h.8pat6j1s0m8g>)
and we needed some additional metadata beyond Dublin Core. We chose to put
the metadata directly in the atom entry for the reason Richard mentioned,
being able to create a new resource or update metadata of an existing
resource with just an atom entry. I also think that it is nice to have all
the metadata together and to have simple rules for where to get the
metadata. The Atom spec (and thus SWORD) allows foreign markup, so we just
added another namespace and include metadata elements from there also in
the same spot where the dc elements are included.
Kathi
On Thu, Feb 9, 2012 at 7:46 AM, Richard Jones <rich...@cottagelabs.com>wrote:
> Hi Samuele,
>
> On Thu, Feb 9, 2012 at 12:59 PM, Samuele Kaplun <samuele.kap...@cern.ch>wrote:
>
>> Hi Richard,
>>
>> In data giovedì, 9 febbraio 2012 12.14:01, Richard Jones ha scritto:
>> > Either of those approaches would work with SWORDv2. The question is
>> > probably whether you ever want to deliver a MARCXML record only to
>> Invenio
>> > without any additional file content. If so, then being able to just
>> post
>> > an atom entry with the embedded metadata would be valuable.
>>
>> thanks a lot for your fast answer. Indeed Invenio was originally designed
>> to
>> handle the MARCXML and later it was extended to support managing digital
>> objects.
>>
>> So definitively it would be a common use case to simply create a resource
>> with
>> just the pure MARCXML record.
>>
>> So if having, within the entry tag, a structured <marc:record> would be
>> regarded as compatible (I was in doubt since in the specs you always
>> mention:
>>
>> "The client SHOULD add Dublin Core [DublinCore] terms to the Atom Entry
>> [...];
>> the terms MUST be embedded as direct children of the atom:entry element
>> [...]"
>>
>> ), with the SWORD profile I would go in this direction.
>>
>
> We put this in the spec because it is very important that every
> implementation has a common understanding of the required DC metadata. For
> further metadata there isn't necessarily the same constraint, so I'd look
> to see if there is any guidance on how MARCXML should be embedded into
> other xml documents (e.g. METS); otherwise, I'd just do whatever feels most
> natural.
>
> Cheers,
>
> Richard
>
>
>
>>
>> Thanks again for your advice!
>>
>> Cheers,
>> Samuele
>> --
>> Samuele Kaplun
>> Invenio Developer ** <http://invenio-software.org/>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> sword-app-tech mailing list
> sword-app-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>
>
--
Katherine Fletcher, kathi.fletc...@gmail.com
<kathi.fletc...@gmail.com>
Twitter: kefletcher <http://www.twitter.com/kefletcher> Blog:
kefletcher.blogspot.com
<kathi.fletc...@gmail.com>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
sword-app-tech mailing list
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
