August 2006 - tdwg-tag - lists.tdwg.org

[tdwg-tapir] Default metadata response
by Javier de la Torre 21 Aug '06

21 Aug '06

Hi all, Just a short question. We agreed on that the default response for a TAPIR service when no operation is sent is metadata. Markus changed that in PyWrapper but by default you also get the protocol headers. My question is if we should not deactivate the protocol header in this case. I prefer not to receive the header. The reason is that then I can attach the same xslt to this xml as the one that we use for displaying the metadata. Javi.

2 2

AW: [tdwg-tapir] TAPIR namespace and versioning
by "Döring, Markus" 15 Aug '06

15 Aug '06

Well, I hope that TAPIR is not changing really. It should be much more stable than our content schemas. So if we include the major version in the namespace I think this is OK. Including the full version number as an attribute into the schema I think is always a good idea. This way we could add minor things to the schema keeping backwards compatability and still discover the exact schema version. I dont think our community currently could handle different major and incompatible versions of a protocol. So negotiating for a version of the protocol seems to me too much too soon. by the way a great album title: http://en.wikipedia.org/wiki/Too_Much_Too_Soon_%28album%29 -- Markus > -----Ursprüngliche Nachricht----- > Von: tdwg-tapir-bounces(a)lists.tdwg.org > [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von > Javier privat > Gesendet: Montag, 31. Juli 2006 01:56 > An: tdwg-tapir(a)lists.tdwg.org > Betreff: [tdwg-tapir] TAPIR namespace and versioning > > Hi all, > > After discussion in Tervuren about ABCD and versioning issues > I thought that we should maybe consider the same strategy for TAPIR. > That is: > > -Do not include the protocol version in the namespace but > rather use always something like http://rs.tdwg.org/tapir > -Use the version attribute in the schema. > -Include a version attribute in the request top element to > specify the TAPIR version of the message. > -A new mandatory version parameter for GET operations called version. > > I even think that we should not change the namespace when > doing non backwards compatible changes to the protocol. > Clients should take care themselves of looking at the version > attribute always. > > This is the way all OGC standards work and I think is a good strategy. > > But this can probably be consider a pretty dramatic change in > the protocol right now... what do you think? I think it would > be great to include this strategy from the beginning so we > are not so worry about breaking clients with possible small > changes in future versions. > > Best regards, > > Javier. > > > > _______________________________________________ > tdwg-tapir mailing list > tdwg-tapir(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir >

3 6

Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: capabilities
by Renato De Giovanni 15 Aug '06

15 Aug '06

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(a)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(a)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(a)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

2 1

[tdwg-tapir] Back from France
by Charles Copp 14 Aug '06

14 Aug '06

Dear all I am sorry for the lack of contact - I have returned from 3 weeks in France - in a forest away from even telephones. I am back now on the TAPIR documentation (once I have read and digested all those emails!) I will try to circulate a first draft soon. Charles

1 0

On vacation next week
by Roger Hyam 11 Aug '06

11 Aug '06

I should mention that I am on vacation next week ( 14th to 18th of August ) so will not be able to respond to posting during that time but will hopefully be fresher and sharper when I return! All the best, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Cardinality - not in Tonto shared ontology
by Roger Hyam 10 Aug '06

10 Aug '06

Hi Everyone, As mentioned in a previous thread I said I would build a justification for not having cardinality in the Tonto shared ontology. In order to do this I will differentiate between: * Semantics: Shared meaning * Application Logic: Statements necessary to do useful things with data within a particular context. Clearly there are semantics in Application Logic. There is meaning in almost anything that isn't purely random but I believe the distinction is important and will be come clear as we go along. Cardinality = "The number of instances of entity B that can (or must) be associated with each instance of entity A." Notation I'll use is: * 0 = none allowed * 1 = one and only one * n...n' = somewhere between n and n' allowed (inclusive). e.g. 0...1 or 1..2 or 1...* (where * is infinite) Take an example: The Person class has the property hasMother that allows instances of Person to have a link to another Person as their mother. The principle of motherhood is a very strong semantic and easy to agree on. Now lets introduce cardinality. Everyone has a mother so the cardinality of hasMother should be 1 - correct? If this is so then systems will say that person objects that don't have a hasMother link to another person are invalid and should be rejected. It is therefore impossible to communicate between systems using the Person class if you don't know who everyones mother is - you can't even use it to ask who their mother is so we have a catch 22. That mother resolver service will have to create it's own semantics. It also rules out use of the Person class in applications that don't care about motherhood - the local pizza delivery shop should not have to have a reference to your mother in order to sell you pizza! So the cardinality of hasMother should be 0...1 - correct? We are now saying that a Person can have 0 or 1 mothers. This isn't semantically correct. Everyone has to have at least 1 mother don't they! It is only instances of the Person *class *that have 0...1 mothers. This is Application Logic not semantics. We are confusing the meaning of the hasMother link with what we want to do with software artifacts. What about an upper bound on this cardinality? Does everyone really have 1 mother? Well if you are adopted you have a birth mother and an adoptive mother. If you have been fostered as well you may have a birth, foster and adoptive mothers. Thanks to IVF you could have separate genetic and birth mothers. So the upper bound of 1 is a little application specific. It doesn't fit if you are running a social services department or IVF clinic but the notion of hasMother does work. You could always communicate with other systems in terms of this person hasMother and simply not express the different mothers roles. In fact the other systems probably wouldn't understand them. So my conclusion from this is that cardinality of properties of objects is application specific and not a matter of shared semantics. Do away with cardinality and we can capture a great deal of useful semantics and communicate using them. Practically is you are running an IVF clinic or orphanage you will have to extend the shared semantic ontology for your particular purposes. Most technologies allow you to do this. I'd be interested in your thoughts on this. All the best, Roger (As we are doing motherhood in this example I promise to try and get Apple Pie into another example) -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

TAG Road Map
by Roger Hyam 09 Aug '06

09 Aug '06

Hi Everyone, The TDWG Infrastructure Project team have a milestone/deliverable to produce a document to act as a road map for the TDWG Architecture. I have prepared a document that I believe pulls together the ideas and consequences from the TAG-1 meeting and the two GUID meetings plus various discussions held at the OGC meeting in Edinburgh. This document introduces the notion of a 'Semantic Hub' which is a proposed mechanism to expose TDWG semantics through multiple technologies: XML Schema; GML; OWL; etc. I would be most grateful if you could find time to have a look at this six page document: http://wiki.tdwg.org/twiki/bin/view/TAG/ArchitectureOverview and give any feedback on the wiki page, via this list or directly to me. Many thanks, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

3 5

RE: [tdwg-tapir] Validation of an outputmodel
by William Ulate 07 Aug '06

07 Aug '06

Hello Javier, I opened the attached file with XMLSpy and it indicates that the file is not valid because it was unable to load the schema with target namespace 'http://rs.tdwg.org/tapir/1.0' from '../../../../tapirProtocol/protocol/tapir.xsd'. I tried it without the relative path: http://rs.tdwg.org/tapir/1.0/tapir.xsd And the error changed to line 14 but of another schema http://rs.tdwg.org/tapir/1.0/w3c_geo.xsd: <dc:title>W3C Basic Geo Vocabulary XML Schema</dc:title> There it stated that: This file is not valid: No Type Definition could be found to validate element 'title'. HTH, William. -----Original Message----- From: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of Javier de la Torre Sent: Domingo, 06 de Agosto de 2006 05:27 p.m. To: tdwg-tapir(a)lists.tdwg.org Subject: [tdwg-tapir] Validation of an outputmodel Hi, Does anybody knows why the attached outputmodel does not validate against the latest tapir schema? I get an error saying: SystemID: /Users/javi/workspace/PyWrapper/webapp/static/models/ getCoordinatesOfTaxon.xml Location: 8:57 Description: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'xs:schema'. URL: http://www.w3.org/TR/xmlschema-1/#cvc-complex-type All the outputmodels in PyWrapper seems to fail in the same way... Thanks in advance. Javi.

2 1

[tdwg-tapir] Validation of an outputmodel
by Javier de la Torre 06 Aug '06

06 Aug '06

Hi, Does anybody knows why the attached outputmodel does not validate against the latest tapir schema? I get an error saying: SystemID: /Users/javi/workspace/PyWrapper/webapp/static/models/ getCoordinatesOfTaxon.xml Location: 8:57 Description: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'xs:schema'. URL: http://www.w3.org/TR/xmlschema-1/#cvc-complex-type All the outputmodels in PyWrapper seems to fail in the same way... Thanks in advance. Javi.

1 0

[tdwg-tapir] BNF Grammar for Filter
by Jose Cuadra 04 Aug '06

04 Aug '06

Hello, Just a short question. Does the BNF Grammar that is listed on http://ww3.bgbm.org/protocolwiki/GetInvokedOperations can be considered the final grammar for Filter expressions? And also, besides the XML Schema, are you going to put a grammar like this one for the complete Tapir protocol? Thanks a lot, Jose Cuadra

2 1