<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="-1"><font face="Verdana">Hi all,<br>
<br>
<font size="-1">Thanks for clarifying th<font size="-1">is<font
size="-1">, we didn't had the whole picture here at BBIF
and were feeling quite lost w<font size="-1">ith this
request</font>.<br>
<br>
<font size="-1">I also think that this <font size="-1">is<font
size="-1"> a rather suboptimal use of the standard.
Anyone who has managed databases (in a broad sens<font
size="-1">e) knows that it's a bad idea to a<font
size="-1">ttach properties to the wrong entity
in order to circumvent a "local" problem. And
when dealing with standards, I guess it's a very
bad idea to change the standard (making things
less clear/more complex for <font size="-1">every</font>one)
only in order to legi<font size="-1">timate this
unusual need.<br>
<br>
<font size="-1">Saying "no" to user requests
is always hard, bu<font size="-1">t
sometimes necessary to <font size="-1">keep
the rest of the world s<font size="-1">ane.<font
size="-1"> We also have to keep in
mind that with<font size="-1"> </font>stan<font
size="-1">dards, once <font
size="-1">we add a <font
size="-1">unappropriate field
(or <font size="-1">a</font>
wrongl<font size="-1">y</font>
placed <font size="-1">field),
w<font size="-1">e'll have
to live with it forever.<br>
<br>
<font size="-1">I can
imagine a fe<font
size="-1">w better
ways for this publis<font
size="-1">her to
solve its problem:<br>
<br>
<font size="-1">1) <font
size="-1">In <font
size="-1">par<font
size="-1">allel
to these
occurences,
derive a
checklist that
use this
extension and
publish both <font
size="-1">in<font
size="-1">
their IP<font
size="-1">T
instance<br>
<font
size="-1">2<font
size="-1">)
Publish this
data in a
custom form i<font
size="-1">n <font
size="-1">one
<font
size="-1">of
the Remarks
fields<br>
<font
size="-1">3)
Create a <font
size="-1">very
<font
size="-1">"provider-specific"</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>
extension <font size="-1">to
pu<font size="-1">blis<font
size="-1">h</font> <font
size="-1">these two
fields only<font
size="-1">. In
that case, I'd al<font
size="-1">so d<font
size="-1">ocument
properly this
extension to
ma<font
size="-1">ke
sure t<font
size="-1">hat
the rest of
the world
understand
it's <font
size="-1">a
very specific
extension that
they probably
shou<font
size="-1">ld
not use.<br>
4) Review
their source <font
size="-1">data
so "species"
attribute are<font
size="-1">
linked to a
species
(rather than
occurrence)
ent<font
size="-1">ity<font
size="-1">.<br>
<br>
Hope I haven't
<font
size="-1"><font
size="-1">offended</font>
anyone, this
is intended to
be
constructive <font
size="-1">criticism.
But IMHO we
have to stay <font
size="-1">firm
with such<font
size="-1"> dec<font
size="-1">isions:
imag<font
size="-1">ine
how the
standard<font
size="-1">
would look
like in a few
years <font
size="-1"><font
size="-1">after
ac<font
size="-1">cepting
<font
size="-1">100
similar
requests from
<font
size="-1">100
d<font
size="-1">ifferent
users ?<br>
<br>
<font
size="-1">Best,<br>
<br>
<font
size="-1">Nicolas</font></font></font></font></font></font></font></font></font></font></font></font></font></font>
</font><br>
</font></font></font></font><br>
</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>
<div class="moz-cite-prefix">On 27/11/12 17:03, "Markus Döring
(GBIF)" wrote:<br>
</div>
<blockquote cite="mid:C3F6C818-D8B0-44B1-9FA9-FCB720085B9F@gbif.org"
type="cite">
<pre wrap="">Hi all,
I agree with all that Peter said and it doesn´t seem appropriate to use the species distribution extension for occurrences. Its the distribution of a species, not of a single occurrence.
Ideally I would also think sharing the threat or Cites status of a species should be done separately in a checklist instead of pushing it all into flat occurrences. But then again Peter pointed out rightly that we do that already for some terms. I would rather remove those taxonomic terms from the occurrence core instead of adding new ones, but Im happily convinced of the opposite :)
Can someone explain the use case a bit more to understand the needs?
best,
Markus
PS: And yes, it sounds like a tdwg content discussion, but then again dwca extensions could be a bit too implementation specific, dont know.
On 26.11.2012, at 13:14, DESMET, Peter wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
Here are my remarks about this request:
As mentioned in the original email, the reason for this request is the need to use threatStatus and appendixCITES for occurrence records.
1) These are properties of taxa, not occurrences. They *could* be used for the taxa referred in an occurrence (and shared in an occurrence dataset), but we have to ask the question if that information cannot be better published as a checklist (using the taxon core) and/or if it should be aggregated/published by that data publisher (the data publisher is often not the source for this kind of data in an occurrence database, it was derived from somewhere else).
Mind you, this is not limited to these terms: we already have several terms from the taxon "class" available in the occurrence core where we have the same issue, e.g. does it make sense to provide information regarding the originalNameUsage or acceptedNameUsage in an occurrence dataset?
So the main question is: do we want to introduce more terms like this?
2) Assuming we accept these terms for occurrence and we use an extension to do so. Do we allow a one-to-many mapping between the occurrence core and the distribution extension? Does it make sense? Isn't that (again) better suited in a checklist?
3) Assuming we only allow a one-to-one mapping, do we need an extension? All terms in the distribution extension are available in the occurrence core, except: threatStatus, appendixCITES and source (this last term should be covered by <a class="moz-txt-link-freetext" href="http://rs.tdwg.org/dwc/terms/index.htm#dcterms:references">http://rs.tdwg.org/dwc/terms/index.htm#dcterms:references</a>).
Maybe (if remark 1 is answered) they should be added to the occurrence core and officially added to the list of Darwin Core terms?
4) Although the question was raised by an IPT user, it might be more useful to have this discussion on the TDWG list? To me this is a conceptual issue first and an implementation issue later.
5) Technical question: why do we need a version increment to the distribution extension if we allow it for occurrences?
Cheers,
Peter
Van: <a class="moz-txt-link-abbreviated" href="mailto:ipt-bounces@lists.gbif.org">ipt-bounces@lists.gbif.org</a> [<a class="moz-txt-link-abbreviated" href="mailto:ipt-bounces@lists.gbif.org">ipt-bounces@lists.gbif.org</a>] namens Tim Robertson [GBIF] [<a class="moz-txt-link-abbreviated" href="mailto:trobertson@gbif.org">trobertson@gbif.org</a>]
Verzonden: donderdag 22 november 2012 9:41
Aan: <a class="moz-txt-link-abbreviated" href="mailto:ipt@lists.gbif.org">ipt@lists.gbif.org</a> mailing list
CC: Danny Vélez
Onderwerp: [IPT] Fwd: "Species Distribution" extension for Occurrence Core in IPT
Dear IPT community,
Please see the request below for using the species distribution extension [1] with occurrence core [2]. This request comes from Colombia, who are setting up an IPT network in the country.
I don't see any issue with this, but wanted to put this through the correct forum (this list) for any comments.
Does anyone have any concerns they would like to raise?
Please note, that extensions are considered immutable in concept, although we allow for minor editorial changes. Therefore this request would warrant a version increment of the distribution extension; reflected in the namespace. IPTs would therefore see 2 species distribution extensions (the second having the new version). The current version cannot be removed as datasets already exist using it, but rather would be marked as "Deprecated" in the description so new installations and updates would show this.
Thanks all,
Tim
[1] <a class="moz-txt-link-freetext" href="http://rs.gbif.org/extension/gbif/1.0/distribution.xml">http://rs.gbif.org/extension/gbif/1.0/distribution.xml</a>
[2] <a class="moz-txt-link-freetext" href="http://rs.gbif.org/core/dwc_occurrence.xml">http://rs.gbif.org/core/dwc_occurrence.xml</a>
* * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * * *
Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver weer en binden het INBO onder geen enkel beding, zolang dit bericht niet bevestigd is door een geldig ondertekend document.
The views expressed in this message and any annex are purely those of the writer and may not be regarded as stating an official position of INBO, as long as the message is not confirmed by a duly signed document. _______________________________________________
IPT mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPT@lists.gbif.org">IPT@lists.gbif.org</a>
<a class="moz-txt-link-freetext" href="http://lists.gbif.org/mailman/listinfo/ipt">http://lists.gbif.org/mailman/listinfo/ipt</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
IPT mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPT@lists.gbif.org">IPT@lists.gbif.org</a>
<a class="moz-txt-link-freetext" href="http://lists.gbif.org/mailman/listinfo/ipt">http://lists.gbif.org/mailman/listinfo/ipt</a>
</pre>
</blockquote>
<br>
</body>
</html>