[PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: capabilities

[Renato De Giovanni]

Hi again,

Now about the dct:modified message...

In DiGIR/DarwinCore networks "DateLastModified" is mandatory both as 
a mapped concept and as a resource attribute inside each metadata 
response. I'm not sure how important it is to force providers to 
include this information even when they cannot get it automatically 
from individual records. It makes a difference for indexers, but they 
can live without this information (basically re-scanning everything 
periodically).

The content of dct:modified could also be manually updated whenever 
there are significant changes in the underlying data. In the worst 
case it would always show us the provider's creation date. But then 
we should probably have dct:modifed and dct:created...

I can't remember if there was any specific reason for not including 
both DublinCore fields. Anyway, it makes sense to have dct:created 
and dct:modified, doesn't matter if optional or mandatory.

Regards,
--
Renato

On 31 Jul 2006 at 15:18, Javier de la Torre wrote:

> Cool,
> 
> Then we dont have to discuss anything. Lets make it optional.
> 
> Cheers.
> 
> On 7/31/06, "Döring, Markus" <m.doering at bgbm.org> wrote:
> > good.
> > PyWrapper caches the metadata in a file and the provider can
> specify how often it should be updated. Usually once a day. Then its
> lightning fast except for the 1 query. But an empty metadata element
> is ok. The schema currently doesnt allow this I think. Should we
> make at least the dct:modified optional? Ah, the ABCDdiscussion
> again...
> >
> > -- Markus
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: pywrapper-devel-bounces at lists.sourceforge.net
> > > [mailto:pywrapper-devel-bounces at lists.sourceforge.net] Im
> > > Auftrag von Renato De Giovanni
> > > Gesendet: Montag, 31. Juli 2006 14:28
> > > An: tdwg-tapir at lists.tdwg.org
> > > Cc: PyWrapper Developers mailing list
> > > Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir:
> > > capabilities
> > >
> > > OK, Markus. Agreed.
> > > But maybe we could also consider an empty metadata response,
> > > because "dct:modified" will likely require interaction with
> > > the DB. And it could take some time for the larger ones
> > > (experience from DiGIR).
> > >
> > > Regards,
> > > --
> > > Renato
> > >
> > > > I have implemented the log-only request now and would like
> > > to suggest
> > > > the
> > > > following:
> > > >
> > > > 1) add "log-only" attribute to responeOperationGroup. Ive
> chosen
> > > > "log-only" cause we already have there an attribute
> "apply-xslt"
> > > > 2) add a mandatory boolean attribute "logRequestsDenied" to
> the
> > > > operation element in a capabilities request
> > > > 3) use existing responses for the log-only request. So if you
> do a
> > > > search with log-only active, you will get an empty search
> response
> > > > back. Thats much easier to implement and doesnt require any
> > > change in
> > > > the schema. The same works with inventories. Pong, Capa &
> Meta
> > > > responses dont cost much anyway, so we could do a normal
> > > response (if
> > > > anyway uses log-only with those requests at all)
> > > >
> > > >
> > > > Does everyone agree to this?
> > > > The schema is already updated for this.
> > > >
> > > >
> > > > Markus