January 2006 - tdwg-tag - lists.tdwg.org

Re: [tdwg-tapir] FAQ page
by Renato De Giovanni 12 Jan '06

12 Jan '06

Hi Javier, Any help with documentation is always welcome - please feel free to make any additions or changes to the FAQ. However it does have a link to the "road map" page, where we tried to put some dates (including one related to DiGIR2, as foreseen by Steve). Best Regards, -- Renato > Dear all, > > We had today the GBIF ICT Expert Group meeting and a lot of people > where making questions about TAPIR. > Seems that there is confusion regarding names. People were asking why > there is Digir 2 if we are all going to TAPIR and things like that. > There were also questions regarding when things are gonna be ready, > what can we expect from Digir2 and TAPIR pywrapper and what would be > the reasons to migrate, how difficult is going to be to migrate, etc. > > I was thinking of extending the FAQ page that Renato started in > Madrid to answer all these questions, but I need some help specially > from the Digir2 people. > > -What is the status of Digir2? > -Is it going to be difficult to update from Digir 1 to 2? > > I will in any case start writing there and maybe you can then modify > extend thins related to you. > > Best regards, > > Javi.

1 0

Re: [tdwg-tapir] tdwg-tapir Digest, Vol 4, Issue 11
by Chuck.Miller＠mobot.org 12 Jan '06

12 Jan '06

Javier, Anton, Dave, Steve, and all, I appeal for a single document/glossary that explains the language and the architecture that all these confusing data exchange standards terms mean. Maybe we need an ontology. A few weeks ago I experienced the same confusion that must have occurred at your meeting after learning about DiGIR2, which I think is a "service". We have things called protocols and schemas and services and providers and portals. Add GUID, which I still think we are short of a single clear understanding of what it is supposed to be, although we have many ideas discussed of what it could be. And don't forget the UDDI, which is called what - service? It's really confusing. And is the GBIF UDDI to be the provider resolver for all protocols and services, or just some? Just to list some of the points of confusion: DiGIR was a protocol but also there was a DiGIR Provider and DiGIR Portal that used the protocol. And several different versions of the DiGIR Provider have now been installed all over the world. And there is the GBIF UDDI. And the GBIF Portal that does more than the original DiGIR Portal. DiGIR required a "federated" schema format, like DarwinCore, but now we have proposals for segmenting a single DarwinCore schema into specialized ones that can be selected and combined by a given provider. What will these new "mini" schemas be called? BioCASE was a protocol and there was a BioCASE Provider and Portal. BioCASE handles the ABCD schema. Does it also handle TCS, SDD, and the other now standard schemas? My impression was that TAPIR was a new protocol to replace DiGIR and BioCASE, but I also then just presumed there would be a TAPIR Provider and Portal, following the past. But, I guess that wasn't the case. So, what will the Provider and Portal for TAPIR called? DiGIR2 now is a service that can utilize any protocol - DiGIR1, TAPIR, and ostensibly BioCASE. But, does it add, replace, augment any of the other existing protocols/schemas? How do Providers and Portals fit in with DiGIR2? Is there a DiGIR2 Provider and DiGIR2 Portal in addition to the DiGIR2 Service? Folks, please, please clarify all this. Finally, it's very dismaying to think these protocol activities may continue to diverge rather than converge. What an opportunity we have right now to unify global data exchange and come together. Chuck Miller Missouri Botanical Garden St. Louis, MO -----Original Message----- From: tdwg-tapir-request(a)lists.tdwg.org [mailto:tdwg-tapir-request@lists.tdwg.org] Sent: Thursday, January 12, 2006 11:00 AM To: tdwg-tapir(a)lists.tdwg.org Subject: tdwg-tapir Digest, Vol 4, Issue 11 Send tdwg-tapir mailing list submissions to tdwg-tapir(a)lists.tdwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org or, via email, send a message with subject or body 'help' to tdwg-tapir-request(a)lists.tdwg.org You can reach the person managing the list at tdwg-tapir-owner(a)lists.tdwg.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tdwg-tapir digest..." Today's Topics: 1. FAQ page (Javier de la Torre) ---------------------------------------------------------------------- Message: 1 Date: Thu, 12 Jan 2006 15:23:08 +0100 From: Javier de la Torre <jatorre(a)gmail.com> Subject: [tdwg-tapir] FAQ page To: tdwg-tapir(a)lists.tdwg.org Message-ID: <69CEC9B7-82F7-4B61-ACB4-5BC097967A20(a)gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, We had today the GBIF ICT Expert Group meeting and a lot of people where making questions about TAPIR. Seems that there is confusion regarding names. People were asking why there is Digir 2 if we are all going to TAPIR and things like that. There were also questions regarding when things are gonna be ready, what can we expect from Digir2 and TAPIR pywrapper and what would be the reasons to migrate, how difficult is going to be to migrate, etc. I was thinking of extending the FAQ page that Renato started in Madrid to answer all these questions, but I need some help specially from the Digir2 people. -What is the status of Digir2? -Is it going to be difficult to update from Digir 1 to 2? I will in any case start writing there and maybe you can then modify extend thins related to you. Best regards, Javi. ------------------------------ _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org End of tdwg-tapir Digest, Vol 4, Issue 11 *****************************************

1 0

Re: [Tdwg-tag] GML application schema for TDWG
by John R. WIECZOREK 09 Jan '06

09 Jan '06

Flip and all, Thanks for that explanation. I can add a point of clarification that might help people's understanding of the intention of the "uncertainty radius." I think the stumbling block for most people is perfectly reflected in the succinct definition Flip has given as an example, "It is intended instead to include the true collection locality with 100% certainty." In fact, the uncertainty radius as we presented it specifically makes no claim to include the true collection locality - it promises only to interpret the primary data consistently. The primary data can be inaccurate. One clear shortcoming of the paper, in retrospect, is that it did not provide a succinct definition of the attribute "uncertainty radius" we were promoting. I would like to venture such a definition now: "The point-radius method (per Wieczorek et al.) describes the sources and rules for combining uncertainties found in the spatial interpretation of textual, descriptive locality data encountered in natural history occurrence data. The 'uncertainty radius' defined by this method is the minumum horizontal linear distance needed to describe a circle, projected onto a geoid, within which lies the entirety of the physical location it is meant to encompass. The uncertainty radius does not establish the verity of the primary data upon which it is based." Once you get deep into the georeferencing business you find that there are a number of additional pieces of information about process and source information from which the end user can benefit. Such is the experience behind the numerous concepts in the proposed geospatial extension to DwC2. It's also the reason why I proposed the unified packaging of geospatial information. I would like to register my support for Flip's recommendation that the point-radius representation (including the metadata beyond the coordinate, coordinate reference system, and distance) be included as the least common denominator geometry in any geospatial schema we develop. John On 1/9/06, Phillip C. Dibner <pcd(a)ecosystem.com> wrote: > > Javier, > > Happy New Year, and thanks for your thoughtful reply (below). I do > think we have a good understanding. > > I've started to answer your email several times, but realized each time > that I might not be addressing your real question. So, for > clarification: you say that the one thing you need is item 1 in your > email below, the geospatial extension. Is the file that I sent you > when I first replied a close approximation to your needs? > > In more detail, and to put things in terms of existing technology, if > we were to recast the files I sent you so that they conform to GML 2, > and permit using only one geometry per feature, would that satisfy your > requirements for a GML application schema (for Darwin Core)? > > As to the data to be incorporated in an application that uses just a > single geometry per feature, I suggest defining the location as a point > with a net uncertainty radius - as a possibly degenerate circle. As I > think I said in my original response to your inquiry, we should require > all implementations to support this, to provide a least common > denominator that would be accessible to all client and server > implementations. I do believe that a polygonal locational description > should be in the schema, but as an option. If a polygon is available, > then a centroid and net uncertainty radius can be computed from it. > > The "net uncertainty radius" mentioned above refers to the method > originally proposed by John Wieczorek and others ("The point-radius > method for georeferencing locality descriptions and calculating > associated uncertainty," INT. J. GEOGRAPHICAL INFORMATION SCIENCE VOL. > 18, NO.8,DECEMBER 2004, 745–767), and proposed as the georeferencing > method to be used in DarwinCore 1.4. It's a bit controversial, I think > mostly because it is an unfamiliar notion: the uncertainty radius as he > defines it is not a traditional statistical error radius. It is > intended instead to include the true collection locality with 100% > certainty. I think a few simple modifications to the definition might > make it more comprehensive and more broadly acceptable. > > I'm actively working on this now, along with several related issues, > and I'll be pleased to stay in touch about progress. > > Please let me know if this message has provided any assistance. > > Thanks and best regards, > Flip > > > > > On Dec 28, 2005, at 7:04 AM, Javier de la Torre wrote: > > > Dear all, > > > > First of all Merry Christmas! Have a nice holidays Flip. > > > > Ok. I think I am starting to understand you better, I am a little bit > > ashamed that I did not attend the Geospatial session last TDWG on > > Saturday, I feel I am a little bit behind on the discussion, would be > > great to get the minutes from this discussion. > > > > Here are some thoughts divided in two different discussions we are > > holding here (sorry if I repeat what you say but I want to be sure I > > understand the discussion): > > > > 1) You are having here a very high Architecture discussion on how to > > proceed with modeling in the TDWG community. I fully agree with you in > > the domain-driven design paradigm that TDWG must take, and your > > proposal for a GML-like thing is interesting, although I am still very > > new to it so I can not well comment on it. In any case this discussion > > must be taken in the TAG mailing list, as Stan suggested, so I would > > not like to continue discussing on this here. > > > > 2) The second discussion is what I am, right now, more interested in > > for my project. How can we share our collection data (ABCD and Darwin > > Core concepts) using WFS and therefore GML. This is interesting for me > > because I would like to create services on top of this. > > In this case what I would like to have is a GML application schema, > > that I can use with WFS (and again we can not be totally blind of the > > status of the art of Open Software for it, for example Geoserver does > > not support GML 3) that contains a good geospatial definition of the > > location of an specimen (that is the geospatial type you have created) > > plus a good definition of the specimen itself as properties of this > > featuretype (that would be ABCD or DWC if you want to be simpler). > > So, apart on how TDWG continues with its modeling process, I think we > > can already start working with OGC standards with our schemas. > > And I do not mean including GML inside ABCD or DWC, but to create a > > GML application schema that make use of ABCD or DWC to define the > > properties of a FeatureType, that is a collection record. Sumarizing > > this is what we need: > > > > 1) a good geospatial set of concepts that describe the localization of > > a collection record and how this has been obtained, etc. (your > > geospatial extension) > > 2) a set of concepts to describe this CollectionRecordType, properties > > of this FeatureType, and for this we created ABCD and Darwin Core. > > 3) a GML application schema that defines a CollectionRecordType from > > the GML AbstractType and that use the two previous "schemas" to define > > the geometry of the type and the properties of it. > > > > So the 3th one is what I called the ABCD-Geospatial-GML-Binding or > > DWC-Geospatial-GML-Binding depending on what do you use to describe > > the CollectionRecord. > > > > So if I consider what is missing for me right now is only the 1st > > point. How to properly described the geometry-georeferenciation of a > > CollectionRecord. The GML application schema to glue the pieces for > > WFS is something, right now unfortunately, that is going to be > > application specific. > > > > So what I would like to concentrate the discussion is on the > > geospatial extension, if we should use serveral geometries, how we > > document georeferenciation, accuracy, etc. This is something a lot of > > people is asking for, I mean, this is fundamental to consider the > > creation of a database or to start a georeferenciation project, and I > > know because in my department they are going to start georeferencing a > > lot of specimen data and I don´t know what to propose them to store > > and how in the database. > > > > At the end I think I am agreeing with you on that the geospatial > > extension should be totally independent, am I? > > > > Thanks for the patience, I know I am repeating a lot of things, but I > > still do not understand totally what is the purpose of this geospatial > > group and I am also very new to GML and OGC. > > > > Best regards, > > > > Javier. > > > > > > > > On 27/12/2005, at 19:25, Phillip C. Dibner wrote: > > > >> Javier, > >> > >> Here's a quick response to your notes and those from some others. > >> Apologies for the delay - I started the following quite a while ago, > >> but was overcome by holiday events. In fact, I will remain fairly > >> constrained between now and the New Year, and will be away from email > >> for a few more days. Still I wanted to send something. > >> > >> Taking a very important comment from your earlier reply: > >> > >>> Then I don't understand how the schemas had been created. I do not > >>> see the connection between dcCollectionRecord and the geospatial. > >>> I would add the geospatial schema to the list of imports of > >>> collection record and add a new element of type Geospatial to it. > >> > >> You are right - there is a complete separation of Geospatial from > >> CollectionRecord. The reason for doing this is that a growing number > >> of extensions to Darwin Core have been proposed. The original way > >> that I incorporated the geospatial extension was exactly as you have > >> suggested. However, I changed my mind when I found out that several > >> additional extensions had been proposed. It is desirable to combine > >> the extensions with the Darwin Core base in any combination that the > >> application might require. This is very cumbersome if they include > >> one another. Therefore, I strongly believe they should be as > >> independent as possible. I If the definitions are separate, they can > >> be combined as required into more complex schemas for other purposes. > >> The entire suite of adopted schemas would share a single namespace, > >> distinguishing them as the suite of objects defined and adopted by > >> TDWG. I made this point in St. Petersburg, (and also at the GML > >> Working Group meeting more recently in Bonn). GML itself uses this > >> pattern. Like GML, we could create a master file that includes all > >> the others. > >> > >> We may wish to define some standard abstract type from which all > >> objects in the TDWG set of schemas inherit. It would be a very > >> simple - and abstract - extension of gml:AbstractFeatureType, to give > >> all of our adopted schema documents a common heritage. > >> > >> We should also keep in mind that the GML information model and its > >> encoding in XML schema are two different things. We should maintain > >> the same notion: our information model is not the same thing as its > >> encoding in GML-compliant XML schema. I favor expressing our model > >> in ISO GML, as expressed in > >> https://www.seegrid.csiro.au/twiki/bin/view/Xmml/UmlGml. > >> > >> Note also that we do not really need to use GML's implementation as > >> XML Schema except where we want to serve our data using WFS. (We may > >> wish to, but that is a separate discussion. Please see below.) And > >> if we do want to use WFS as currently defined, and thus avail > >> ourselves of all the off-the-shelf software that supports it, we must > >> have an expression of our concepts in GML as currently specified. > >> That's the only technology available for this. Again, however, our > >> information model need only be consistent with it, and encodable in > >> such a form. It does not need to be defined by this form (and due > >> to some of the restrictions of XML Schema, I think it should not be). > >> > >> In St. Petersburg I also talked about the value of having a small > >> snippet of GML to add to the existing ABCD or DarwinCore-for-DiGIR > >> schemas, as you have suggested. That may be a good thing to have, > >> but it is a separate discussion. If we make these definitions, we > >> should have a fairly clear idea of what we'll want to use them for. > >> The schemas with extensions of this sort cannot be served by a WFS. > >> They may, however, be parsed, and the relevant portions analyzed by > >> some specialized geospatial extension to DiGIR (or other) clients, or > >> by adjunct geospatial packages that understand GML. > >> > >> Again, this is just a quick response, hastened all the more by the > >> fact that I have to depart for a few days. I will engage much more > >> fully in this discussion after the New Year, which I hope is a happy > >> and enjoyable occasion for all of you. > >> > >> Very best regards, > >> Flip > >> > >> > >> On Dec 20, 2005, at 7:58 AM, Javier de la Torre wrote: > >> > >>> Hi Flip, > >>> > >>> I've been playing a little bit more with the schemas. Here are some > >>> ideas: > >>> > >>> I think I am still not understaind the way you would like to > >>> implement the schemas, but here is an idea on how to do it for ABCD > >>> and for Darwin Core: > >>> > >>> The main idea is to create a CollectionRecordType in a document > >>> called something like abcd2.06_gml_biding.xsd or > >>> dwc2_gml_binding.xsd > >>> What this schema does is to create an element called > >>> CollectionRecordType that extends the AbstractFeatureType of GML and > >>> that includes two elements in a sequence: Unit or Record of type > >>> "abcd:Unit" or "dwc:Record" and another element called Geospatial of > >>> type "tdwg_geo:GeospatialType". The schema imports GML, ABCD, and > >>> your Geospatial schema. > >>> > >>> We only create the binding between our actual schemas and GML and > >>> then we add also a GeospatialExtension to them. > >>> > >>> Here is an example: > >>> --------- > >>> <?xml version="1.0" encoding="UTF-8"?> > >>> <xsd:schema.....> > >>> <xsd:import namespace="http://www.opengis.net/gml " > >>> schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/gml.xsd"/<http://schemas.opengis.net/gml/3.1.1/base/gml.xsd%22/> > > > >>> <xsd:import namespace=" http://www.tdwg.org/schemas/abcd/2.06" > >>> schemaLocation="http://www.bgbm.org/TDWG/CODATA/Schema/ABCD_2.06/ > >>> ABCD_2.06.XSD"/> > >>> <xsd:import namespace="http://www.tdwg.org/schemas/geo_spatial/1.0 > " > >>> schemaLocation=" http://gis.grinfo.net/resources/ > >>> dcGeospatial_javi.xsd"/> > >>> <xsd:complexType name="CollectionRecordType"> > >>> <xsd:complexContent> > >>> <xsd:extension base="gml:AbstractFeatureType"> > >>> <xsd:sequence> > >>> <xsd:element name="Unit" > type="abcd:Unit"/> > >>> <xsd:element name="Geospatial" > type="tdwg_geo:GeospatialType"/> > >>> </xsd:sequence> > >>> </xsd:extension> > >>> </xsd:complexContent> > >>> </xsd:complexType> > >>> <xsd:element name="CollectionRecord" type="CollectionRecordType" > >>> substitutionGroup="gml:_Feature"/> > >>> </xsd:schema> > >>> -------------------------- > >>> > >>> I do not like it specially like this... Is not possible to extend > >>> something from two types in XML schema no? this is why I have to > >>> repeat CollectionRecord and then Unit... > >>> > >>> I don't know. In any case now I think I understand that what you > >>> want is to separate the extension from the binding, is that correct? > >>> > Phillip C. Dibner > Ecosystem Associates > (650) 948-3537 > (650) 948-7895 Fax

1 0

Re: [tdwg-tapir] reload / expire external resources
by John R. WIECZOREK 06 Jan '06

06 Jan '06

Markus et al., I agree with your assessment. I believe it is essential to have a mechanism to overcome network inaccessibility of the schemas. Any added complexity in this respect will be worth it. John

1 0

Re: [tdwg-tapir] tapir namespace
by John R. WIECZOREK 06 Jan '06

06 Jan '06

I would have thought that one more level might be warranted for organizational purposes, specifically, http://www.tdwg.org/schemas/protocol/tapir/1.0

1 0

[tdwg-tapir] tapir namespace
by "Döring, Markus" 06 Jan '06

06 Jan '06

Hi, another thing is the namespace of TAPIR. Currently its http://www.tdwg.org/schemas/tapir/datasource/1.0 Are there guidelines from tdwg for this? Do we still need the "datasource" being part of the url? Initially this was done to indicate that this protocol only specifies the communication to/from a datasource and not between portals, aggregators, proxies or relays, ... But are we still thinking of creating a family of TAPIR protocols? Personally I am quite indifferent. I would be happy with just a short one such as: http://www.tdwg.org/tapir/1.0 Any opinions on this? Markus

4 3

Re: [tdwg-tapir] tapir namespace
by "Döring, Markus" 06 Jan '06

06 Jan '06

Hmmm. I remember Gregor talking about best practices regarding schema versioning. And I think I remember that the current advice on this is that namespaces stay the same as long as the validation of existing documents is not affected. So clearly adding a comment and updating doc strings does not influence the namespace. Changing a local element definition into a reference to a global one should still be fine I guess. But adding new elements or even removing them surely requires a new namespace. Here are 2 interesting docs about this subject (linked from stylusstudio): 1. Should the targetNamespace be a URL or a URN? http://www.xfront.com/URLversusURN.pdf 2. What's the best way to version schemas? http://www.xfront.com/Versioning.pdf >>>From The XML Schema: Best Practices Home Page at: http://www.xfront.com/BestPracticesHomepage.html Or another one: http://xml.coverpages.org/HP-StephensonSchemaBestPractices.pdf They are mainly suggesting to deal with 2 kinds of versions: * Major-completely different structure and semantics, most likely not backward compatible, new versions of applications are written to use new asset version * Minor-backward compatible changes which introduce new features without removing or changing the semantics of existing structures "The best practice for encoding these two version numbers in an evolving XML schema is to encode the major version inside the target XML namespace of the XML schema and to encode the minor version in the schema version attribute." Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Freitag, 6. Januar 2006 13:40 An: tdwg-tapir(a)lists.tdwg.org Cc: lee(a)tdwg.org Betreff: Re: [tdwg-tapir] tapir namespace Hi Roger, I think it would be quite convenient to have all relevant documents (specification, overview, XML Schema) easily available from wherever the namespace URI gets resolved to. Even if it just resolves to a simple directory listing. There might be cases when the XML Schema needs to be changed and the other docs would remain unchanged. For each XML Schema release, I think a new namespace needs to be created, and even if the other docs are the same they can just be copied from the previous release (or maybe use symbolic links to point to them). That would be a simple and effective way to handle this. If TDWG changes its name, it will certainly need to keep the old domain and setup redirects to the new domain when necessary. Namespaces are just identifiers, and should not be affected. They will just be referencing/advertising the old name when they are used. Best Regards, -- Renato On 6 Jan 2006 at 11:47, Roger Hyam wrote: > Hi All, > > Ricardo and I just discussed namespaces and schema locations without > coming to a conclusion. TDWG needs a namespace and schema location > policy and we need to reserve a space for these as we put the > infrastructure in place. > > There are a host of issues to resolve including how we do resources in > ontologies, what happens if you try and resolve a namespace URI - do > you get a page not found, a generic message saying it is a namespace > or specific message or a redirect etc. Should the schema location be > the same as the standard location or embedded within it. Also we need > to have 'permanent' URLs for standards themselves. Oh and what happens > if we change the name of the organisation as people bring up from time to time! > > Some of the issues are closely related to GUID stuff so I am hope that > we can have a very brief discussion about it at the GUID meeting over > a beer and just decide on a load of these things. Many things are more > or less arbitrary and a decision just needs to be taken - any decision. > > Can you wait till February for a final policy on what the namespace > URIs will look like? > > I suggest namespaces will be of the form > > http://tdwg.org/namespaces/tapir/what_you_like > > (note no www as it is not a web thing. We could go for > namespaces.tdwg.org/tapir ...) > > and schema stuff might be like this: > > http://www.tdwg.org/standards/tdwg_std_tapir_20060130/schema.xsd > > My big question is: Will the schema change without the standard changing? > > There would also be other related to the standard at: > > http://www.tdwg.org/standards/tdwg_std_tapir_20060130/ > > including the normative documentation and a cover page xml document > with metadata for the standard. > > Does this make sense? I'd appreciate feedback as I am actively working > on the specification for all this stuff. > > Thanks, > > Roger _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

1 0

Re: [tdwg-tapir] tapir namespace
by "Döring, Markus" 06 Jan '06

06 Jan '06

Hi Roger, just some quick notes I had in mind when reading your mail. I really like to have the schema and its documentation behind the namespace. I dont know of a reason why namespaces should point into nothing. For the domain I like the idea of namespace.tdwg.org or maybe standards.tdwg.org The schema file itself would better be named tapir.xsd or something other more descriptive than schema.xsd. Whether the pure directory http://ns.tdwg.org/tapir/1.0 resolves immediately to the schema or just an index page that links to the schema and further links I dont know. It would be great if its the schema, but then how do you know about the documentation? Just quick notes as I said. But I am sure we can change the namespace by February - as long as there arent that many applications existing... Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Roger Hyam Gesendet: Freitag, 6. Januar 2006 12:47 An: Döring, Markus Cc: lee(a)tdwg.org; tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] tapir namespace Hi All, Ricardo and I just discussed namespaces and schema locations without coming to a conclusion. TDWG needs a namespace and schema location policy and we need to reserve a space for these as we put the infrastructure in place. There are a host of issues to resolve including how we do resources in ontologies, what happens if you try and resolve a namespace URI - do you get a page not found, a generic message saying it is a namespace or specific message or a redirect etc. Should the schema location be the same as the standard location or embedded within it. Also we need to have 'permanent' URLs for standards themselves. Oh and what happens if we change the name of the organisation as people bring up from time to time! Some of the issues are closely related to GUID stuff so I am hope that we can have a very brief discussion about it at the GUID meeting over a beer and just decide on a load of these things. Many things are more or less arbitrary and a decision just needs to be taken - any decision. Can you wait till February for a final policy on what the namespace URIs will look like? I suggest namespaces will be of the form http://tdwg.org/namespaces/tapir/what_you_like (note no www as it is not a web thing. We could go for namespaces.tdwg.org/tapir ...) and schema stuff might be like this: http://www.tdwg.org/standards/tdwg_std_tapir_20060130/schema.xsd My big question is: Will the schema change without the standard changing? There would also be other related to the standard at: http://www.tdwg.org/standards/tdwg_std_tapir_20060130/ including the normative documentation and a cover page xml document with metadata for the standard. Does this make sense? I'd appreciate feedback as I am actively working on the specification for all this stuff. Thanks, Roger Döring, Markus wrote: > Hi, > another thing is the namespace of TAPIR. > Currently its http://www.tdwg.org/schemas/tapir/datasource/1.0 > > Are there guidelines from tdwg for this? > Do we still need the "datasource" being part of the url? Initially this was done to indicate that this protocol only specifies the communication to/from a datasource and not between portals, aggregators, proxies or relays, ... > But are we still thinking of creating a family of TAPIR protocols? > > Personally I am quite indifferent. I would be happy with just a short one such as: > http://www.tdwg.org/tapir/1.0 > > Any opinions on this? > > Markus > > > _______________________________________________ > tdwg-tapir mailing list > tdwg-tapir(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 ------------------------------------- _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

1 0

[tdwg-tapir] tapir schema changes summary
by "Döring, Markus" 06 Jan '06

06 Jan '06

Hello, on top of Renato's larger schema update, I have just edited the TAPIR schema to conform to the following changes. Most of them we discussed on this list before or are pure cosmetic changes to provide a more consistent schema. Markus REAL SEMANTIC CHANGES - add label & documentation element to output model via new extResourceDocumentationType - remove reload flag for the outputModel in searchTemplateGroup/outputModel - subdivide abstract expression element into simple&complex expression, with literals,concepts&parameters being simple, arithmetic OPs complex expressions. - allow IN operator to have only simple expressions as arguments REMOVED ERRORS - capabilities/variables/environment/variable should be unbounded - capabilities/variables/environment/custom should reference global element COSMETIC SCHEMA ADJUSTMENTS - use externalResourceType for outputModel link in searchTemplateGroup/outputModel (named outputModelURI before) - rename outputModelGroup/structure/schemaLocation into "schema" and also use the externalResourceType - change all template related Groups into ComplexTypes - add to all complex/simple type names "Type" if not yet named like this

1 0

[tdwg-tapir] Schema modification: r404 - trunk/protocol/examples
by tdwg-tapir＠lists.tdwg.org 06 Jan '06

06 Jan '06

Author: markus Date: 2006-01-06 11:03:46 +0100 (Fri, 06 Jan 2006) New Revision: 404 Modified: trunk/protocol/examples/inventory_template1.xml trunk/protocol/examples/search_template1.xml Log: moved the filter element to validate against the latest TAPIR schema Modified: trunk/protocol/examples/inventory_template1.xml =================================================================== --- trunk/protocol/examples/inventory_template1.xml 2006-01-06 09:57:27 UTC (rev 403) +++ trunk/protocol/examples/inventory_template1.xml 2006-01-06 10:03:46 UTC (rev 404) @@ -5,13 +5,13 @@ <label>Specimen Names</label> <documentation>Search and list unique scientific names of specimen identifications ordered alphabetically by their name. The filter parameter "name" is used to build the filter</documentation> + <concepts> + <concept id="dwc:/ScientificName"/> + </concepts> <filter> <like> <concept id="dwc:/ScientificName"/> <parameter name="name"/> </like> </filter> - <concepts> - <concept id="dwc:/ScientificName"/> - </concepts> </inventoryTemplate> Modified: trunk/protocol/examples/search_template1.xml =================================================================== --- trunk/protocol/examples/search_template1.xml 2006-01-06 09:57:27 UTC (rev 403) +++ trunk/protocol/examples/search_template1.xml 2006-01-06 10:03:46 UTC (rev 404) @@ -5,13 +5,13 @@ <label>Specimen by Name</label> <documentation>Search specimens by their scientific name. Result is returned ordered by name and catalogue number. The filter parameter "name" is used to build the filter.</documentation> + <outputModel location="http://the.same.host/output_model1.xml"/> <filter> <like> <concept id="dwc:/ScientificName"/> <parameter name="name"/> </like> </filter> - <outputModel location="http://the.same.host/output_model1.xml"/> <orderBy> <concept id="dwc:/ScientificName"/> <concept id="dwc:/CatalogNumber"/>

1 0