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@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@lists.sourceforge.net [mailto:pywrapper-devel-bounces@lists.sourceforge.net] Im Auftrag von Renato De Giovanni Gesendet: Montag, 31. Juli 2006 14:28 An: tdwg-tapir@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:
- add "log-only" attribute to responeOperationGroup. Ive
chosen
"log-only" cause we already have there an attribute
"apply-xslt"
- 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