<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.5730.11" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV>I completely agree - back to "model it first using a serialisation independent method", eg UML, then work towards specific schemas for specific use cases which are "solution oriented" rather than a modeling technique.</DIV>
<DIV> </DIV>
<DIV>I always wondered whether schemas such as DwC are more like "suggested implementations" or "best practices" for specific models and specific use cases. Eg DwC could be represented as the best practice transfer standard for <U>simple</U> specimen/observation records (using xml or rdf?), referencing a standard set of "concepts" (by URI), and use a format like:</DIV>
<DIV> </DIV>
<DIV><xs:schema targetNamespace="<A href="http://rs.tdwg.org/dwc/dwcore/">http://rs.tdwg.org/dwc/dwcore/</A>"<BR> xmlns:dwe="<A href="http://rs.tdwg.org/dwc/dwelement">http://rs.tdwg.org/dwc/dwelement</A>" <BR> xmlns:dwc="<A href="http://rs.tdwg.org/dwc/dwcore/">http://rs.tdwg.org/dwc/dwcore/</A>" <BR> xmlns:xs="<A href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"<BR> elementFormDefault="qualified" version="0.7"</DIV>
<DIV> xmlns:tto="<A href="http://rs.tdwg.org/ontology/voc/TaxonOccurrence">http://rs.tdwg.org/ontology/voc/TaxonOccurrence</A>#" ></DIV>
<DIV> </DIV>
<DIV>...</DIV>
<DIV> <xs:element ref="<A href="http://rs.tdwg.org/ontology/voc/TaxonOccurrence#basisOfRecordString">tto:basisOfRecordString</A>" minOccurs="1" /></DIV>
<DIV> <xs:element ref="<A href='http://rs.tdwg.org/ontology/voc/TaxonOccurrence#identifiedTo"/'>tto:identifiedToString</A>" minOccurs="1" /></DIV>
<DIV>...</DIV>
<DIV> </DIV>
<DIV></xs:schema></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Let me know if this is complete rubbish??</DIV>
<DIV>Kevin</DIV>
<DIV> </DIV><BR><BR>>>> "Roger Hyam (TDWG)" <rogerhyam@mac.com> 4/06/2008 8:33 p.m. >>><BR><BR>My only wish is that each 'concept' within DwC consists of a normative <BR>description bound to a URI. We can then use these definitions across <BR>technologies.<BR><BR>I would even suggest that the standard takes the form of a human <BR>readable table of URIs and definitions and any talk of XML Schema, <BR>RDF, CSV etc is left either to later sections of the standard or even <BR>totally separate standards.<BR><BR>My belief is that the pain we suffer now is because the 'things' were <BR>not defined separately from the technology so it is not possible to <BR>conceptually map between the transfer formats.<BR><BR>Just my thoughts,<BR><BR>Roger<BR><BR><BR><BR>On 29 May 2008, at 21:43, Renato De Giovanni wrote:<BR><BR>> John et al.,<BR>><BR>> I think it's a good idea to use a survey to test for consensus, but it<BR>> should be as simple as possible. I would suggest perhaps two <BR>> questions:<BR>><BR>> --------------<BR>> 1- Would you be satisfied if the current DarwinCore and its two <BR>> extensions<BR>> (curatorial and geospatial) become an official standard? (even if you<BR>> don't fully agree with everything).<BR>><BR>> yes/no<BR>><BR>> 2- If not, what do you think should still be improved/fixed?<BR>><BR>> [text]<BR>> ---------------<BR>><BR>> Regarding your questions, maybe it would be interesting to move the<BR>> discussion to the Wiki so that more people can participate and all <BR>> answers<BR>> can be visualized together.<BR>><BR>> I agree with Dave that it's important to define the nature of DwC.<BR>> Personally, I see it as an XML vocabulary, not a real data model as <BR>> the<BR>> TDWG ontology.<BR>><BR>> Now my answers:<BR>><BR>> 1) Yes, I agree that species occurrence would be the right scope for <BR>> the<BR>> core. However, I agree with Hannu that some concepts in the core can<BR>> easily cause confusion when interpreted by field observers. A few<BR>> adjustments in concept names and perhaps a new observation extension <BR>> could<BR>> be worthwhile.<BR>><BR>> As a side note, if we decide to make any changes in the existing <BR>> schemas<BR>> it's important to change the namespace because they are already <BR>> being used<BR>> by providers. It's possible to map concepts from two schemas if they <BR>> have<BR>> different namespaces (see <A href="http://rs.tdwg.org/tapir/cs/mappings/)">http://rs.tdwg.org/tapir/cs/mappings/)</A> <BR>> allowing<BR>> providers to easily upgrade their configuration when necessary.<BR>><BR>> 2) Fully agree with Dave.<BR>><BR>> 3) Fully agree with Dave and Hannu.<BR>><BR>> 4) I tend to agree with John, unless we expect that a few<BR>> observation/specimen data providers will be able to offer additional <BR>> GUIDs<BR>> (such as taxon concept GUIDs) in the next years. I doubt this will <BR>> happen<BR>> soon, but I may be wrong.<BR>><BR>> 5) I see the current application schema more as an example. There <BR>> can be<BR>> as many application schemas as necessary from TAPIR's perspective. <BR>> This<BR>> one works well for flat data structures. ABCD or something along the <BR>> lines<BR>> of Markus' new schema would be better options when there can be <BR>> repeatable<BR>> elements.<BR>><BR>> 6) Fully agree with John's answer. I think it's important to allow <BR>> data<BR>> cleaning through valid XML instances.<BR>><BR>> Best Regards,<BR>> --<BR>> Renato<BR>><BR>><BR>>> I got sidetracked on this days ago, but feel in the light of recent <BR>>> star<BR>>> schema discussions on the original caching thread that the time is <BR>>> again<BR>>> right to submit this new discussion.<BR>>><BR>>> Tradition has DwC discussions on this Tapir mailing list. I'm <BR>>> starting<BR>>> this<BR>>> new thread based on Markus' recent posting (below) about an <BR>>> Identification<BR>>> extension to DwC. I'm motivated to pull together the time and <BR>>> energy to<BR>>> finally push the pending DwC through the standards process, with a <BR>>> goal of<BR>>> having that whole process finished by the TDWG Meeting this year.<BR>>> I've been thinking about how to conduct the Request for Comment <BR>>> required<BR>>> to<BR>>> move the standard forward. I propose to put together a survey with <BR>>> Survey<BR>>> Monkey or something akin to actually test for reasonble concensus. <BR>>> Any<BR>>> comments or suggestions about this idea are welcome.<BR>>> However, I see benefits to having further discussion about some key <BR>>> issues<BR>>> before doing that, as I believe we now have enough accumulated <BR>>> experience<BR>>> to<BR>>> make some good decisions that will affect the design and guidelines <BR>>> for<BR>>> further development of the Darwin core and extensions.<BR>>><BR>>> In the past, most Darwin Core discussions have revolved about <BR>>> whether to<BR>>> include a particular concept, and where. I think it will be much more<BR>>> useful<BR>>> to concentrate on a few key issues at a higher level, resolve them <BR>>> at that<BR>>> level, then make any necessary changes to the schemas based on the<BR>>> consensus<BR>>> guiding principles. It should be easy and fast to accomplish this <BR>>> if the<BR>>> principles are clear and simple. It should be possible to complete <BR>>> this<BR>>> work<BR>>> soon if we can easily achieve a concensus. Here are some seed <BR>>> questions<BR>>> and<BR>>> recommendations to facilitate the resolution if this next step in the<BR>>> process.<BR>>><BR>>> 1) Is species occurrence in nature and in collections the right <BR>>> scope for<BR>>> the Core?<BR>>> 2) Should the general philosophy of the Core be inclusive or <BR>>> minimalist?<BR>>> What are the characteristics of a concept that allow it to be in <BR>>> the Core?<BR>>> What are the characteristics of a concept that allow it to be added <BR>>> to an<BR>>> existing extension?<BR>>> 3) What are the defining characteristics of a group of related <BR>>> concepts<BR>>> that<BR>>> justify the creation of a new extension? Should extensions be based <BR>>> on<BR>>> abstract conceptual groupings/objects (events,<BR>>> identifications/determinations, places)? Or on special interests <BR>>> (paleo,<BR>>> curation, interaction)? Or on the stability of the concepts (core <BR>>> contains<BR>>> the proven stable concepts, extensions are more volatile)?<BR>>> 4) Should there be elements in the Core and extensions to hold GUIDs<BR>>> linking<BR>>> them to instances of related classes of objects, such as an <BR>>> occurrence to<BR>>> a<BR>>> TaxonConceptGUID, or an occurrence to a CoreGatheringGUID? Should <BR>>> every<BR>>> extension have a non-mandatory GUID allowing for the external <BR>>> resolution<BR>>> of<BR>>> the object?<BR>>> 5) What should the Darwin Tapir application schema look like?<BR>>> 6) Is it the right approach to have restrictions on content at the <BR>>> concept<BR>>> definition level? Where should the line be drawn? Arguments have been<BR>>> raised<BR>>> in the past about the DwC and extensions' content with respect to<BR>>> being restrictive versus open to incorrect content. For example, <BR>>> DayOfYear<BR>>> in the current DwC 1.4 (http://rs.tdwg.org/dwc/tdwg_dw_core.xsd) is <BR>>> typed<BR>>> as<BR>>> a dwc:dayOfYearDataType, which is defined in<BR>>> <A href="http://rs.tdwg.org/dwc/tdwg_basetypes.xsd">http://rs.tdwg.org/dwc/tdwg_basetypes.xsd</A> as:<BR>>><BR>>> <xs:simpleType name="dayOfYearDataType"><BR>>> <xs:restriction base="xs:integer"><BR>>> <xs:minInclusive value="1" /><BR>>> <xs:maxInclusive value="366" /><BR>>> </xs:restriction><BR>>> </xs:simpleType><BR>>><BR>>> Anything short of a flamethrower in response is welcome.<BR>><BR>><BR>> _______________________________________________<BR>> tdwg-tapir mailing list<BR>> tdwg-tapir@lists.tdwg.org<BR>> <A href="http://lists.tdwg.org/mailman/listinfo/tdwg">http://lists.tdwg.org/mailman/listinfo/tdwg</A>-tapir<BR><BR>_______________________________________________<BR>tdwg-tapir mailing list<BR>tdwg-tapir@lists.tdwg.org<BR><A href="http://lists.tdwg.org/mailman/listinfo/tdwg">http://lists.tdwg.org/mailman/listinfo/tdwg</A>-tapir<BR><BR>
<div style="margin-left: 4px; line-height: normal; margin-right: 4px; font-variant: normal; margin-bottom: 1px; margin-top: 4px">
<p>
<img src="cid:DSHJZOEKAYVF.46e1787f.jpg" border="0">
<font face="Book Antiqua" color="#006600" size="4">Please consider the
environment before printing this email </font>
</p>
<p>
<strong><font face="Book Antiqua" size="2">WARNING</font></strong><font face="Book Antiqua" size="2">
: This email and any attachments may be confidential and/or privileged. They
are intended for the addressee only and are not to be read, used,
copied or disseminated by anyone receiving them in error. If you are
not the intended recipient, please notify the sender by return email
and delete this message and any attachments.<br><br>The views
expressed in this email are those of the sender and do not necessarily
reflect the<br>official views of Landcare Research. </font><a href="http://www.landcareresearch.co.nz"><font face="Book Antiqua" color="#0000ff" size="2"><u>
http://www.landcareresearch.co.nz</u></font></a><font face="Book Antiqua" color="#0000ff" size="2">
</font>
</p>
</div>
</BODY></HTML>