<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
With respect to item 1: <br>
<br>
I would support changing to a different RDF document from
<a class="moz-txt-link-freetext" href="http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf">http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf</a> to something else.  When
a semantic client dereferences a DwC term and requests content-type:
application/rdf+xml, it is not served the normative document.  It gets
a different one (dwcterms.rdf ?).  At least this is what happened in
the past when I tested this.  It has never been clear to me how a
client is supposed to "follow its nose" to find the normative
definitions.  The normative document is further complicated by having
URIs with appended dates which I suppose are connected to the non-dated
versions in some way - again, I'm not clear how.  <br>
<br>
It seems more straightforward to me for the normative document to
contain the URIs and metadata for the most recent (undated) versions of
all terms, whether they be recommended or deprecated.  If a term is
deprecated, it shouldn't "disappear from sight".  Rather, its metadata
should indicate that it's deprecated using the standard property:<br>
<br>
<pre>&lt;owl:deprecated rdf:datatype="&amp;xsd;boolean"&gt;true&lt;/owl:deprecated&gt;</pre>
I'm not sure that I get the distinction between "deprecated" and
"obsolete".  Can't all terms just be either currently recommended or
deprecated?  Terms should never go away in the RDF, they should be
marked as deprecated.  Whether we want humans to see them on a quick
reference guide is another story.  <br>
<br>
Please note that I'm not taking a position on items 2 or 3.  Item one
simply maintains the status quo (normative document=RDF) and just
substitutes one particular document with another.<br>
<br>
Steve<br>
<br>
Steve Baskauf wrote:
<blockquote cite="mid:54C00104.6020105@vanderbilt.edu" type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
I should have said this in my earlier message, but many thanks to John,
Peter, and Markus for getting things streamlined and moved to GitHub.  <br>
  <br>
I think that it would be best to break this proposal into four parts:<br>
1. should we change the identity and form of the DwC normative RDF
document?<br>
2. should the DwC normative document be expressed as RDF?<br>
3. should a single normative document be the entire standard, with
other supporting documents being outside of the standard and modifiable
without going through an official process?<br>
4. should the DwC namespace policy be adopted TDWG-wide?<br>
  <br>
Each of these parts need to be discussed separately - having them as a
package makes it difficult to say "I support the proposal" or "I oppose
the proposal".  I feel that item 1 could be addressed during a public
comment period and action taken based on the outcome of that
discussion.  It's really a technical issue.  But items 2-4 are really
policy decisions about process that I don't think can be addressed
effectively on an email list.  I think they would be better addressed
as a task group level, with an examination of what has and hasn't
worked for TDWG and other organizations, a record of discussion, list
of pros-and-cons, and a consensus recommendation by the task group, all
documented on a wiki or in a report.  At that point, those who care can
review the recommendations and comment on tdwg-content.  We've learned
in the past that tdwg-content just isn't an effective way to hash out
these complicated kind of decisions.<br>
  <br>
Steve<br>
  <br>
Markus Döring wrote:
  <blockquote cite="mid:BFE61A12-DF66-48F5-959B-997A341E8DBB@gbif.org"
 type="cite"> Bob, 
    <div>I am surprised about the dislike of RDF being normative for
DwC.
This has been the case for years[1] and noone did mind.
    <div>The changes we propose focus on keeping out the history and
the
namespace policy document.</div>
    <div><br>
    </div>
    <div>The issue I would like to think about a little more is how to
best deal with deprecated terms. </div>
    <div>Is it good enough if those term URIs would resolve to a
section
within the html history document or do we need to return rdf for them?</div>
    <div><br>
    </div>
    <div>Markus</div>
    <div><br>
    </div>
    <div><br>
    </div>
    <div>[1] <a moz-do-not-send="true" href="http://rs.tdwg.org/dwc/">http://rs.tdwg.org/dwc/</a><br>
    <div>"<span
 style="font-family: Verdana,Arial,'Arial Unicode MS',Helvetica,sans-serif; font-size: small; background-color: rgb(255, 255, 255);">The
normative document for the terms [</span><a moz-do-not-send="true"
 href="http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf"
 style="color: rgb(102, 102, 102); font-family: Verdana,Arial,'Arial Unicode MS',Helvetica,sans-serif; font-size: small; background-color: rgb(255, 255, 255);">RDF-NORMATIVE</a><span
 style="font-family: Verdana,Arial,'Arial Unicode MS',Helvetica,sans-serif; font-size: small; background-color: rgb(255, 255, 255);">]
is written in the Resource Description Framework (RDF)</span><font
 face="Verdana, Arial, Arial Unicode MS, Helvetica, sans-serif" size="2">”</font></div>
    <div><font
 face="Verdana, Arial, Arial Unicode MS, Helvetica, sans-serif" size="2"><br>
    </font></div>
    <div><font
 face="Verdana, Arial, Arial Unicode MS, Helvetica, sans-serif" size="2"><span
 style="background-color: rgb(255, 255, 255);"><br>
    </span></font>
    <div>
    <div>On 21 Jan 2015, at 17:34, Bob Morris &lt;<a
 moz-do-not-send="true" href="mailto:morris.bob@gmail.com">morris.bob@gmail.com</a>&gt;
wrote:</div>
    <br class="Apple-interchange-newline">
    <blockquote type="cite">
      <div
 style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">Be
wary; very, very wary. If RDF is the normative artifact for DwC,<br>
there will be ambiguity about Containers and, less so, about Lists,<br>
both of which are somewhere between non-existent and horrifying in<br>
RDF.  My prediction is that "DwC.rdf" will end up needing to be<br>
expressed in OWL, and that the specification of lists, of unordered<br>
sets, and of cardinality restrictions, will mystify most readers<br>
hoping to discuss the standard.<br>
      <br>
      <br>
On Wed, Jan 21, 2015 at 10:49 AM, Éamonn Ó Tuama [GBIF]<br>
&lt;<a moz-do-not-send="true" href="mailto:eotuama@gbif.org">eotuama@gbif.org</a>&gt;
wrote:<br>
      <blockquote type="cite">Seems like RDF expression in combination
with a privileged XSLT to human readable doc might do. I still like the
idea of the RDF doc as the normative one. At least it is concise. The
W3C specification pages are a rather messy mix of different sections
some headed by "This section is non-normative.", and see, e.g., the
page for the DCAT vocab [1] "As well as sections marked as
non-normative, all authoring guidelines, diagrams, examples, and notes
in this specification are non-normative. Everything else in this
specification is normative."<br>
        <br>
While RDF might excel as a graph definition langauge, I think there is
still value is using it without domain and range statements (if these
don't exist) to simply define labels, definitions and comments
(examples) in a machine readable way.<br>
        <br>
        <br>
        <br>
[1] <a moz-do-not-send="true" href="http://www.w3.org/TR/vocab-dcat/">http://www.w3.org/TR/vocab-dcat/</a><br>
        <br>
-----Original Message-----<br>
From: <a moz-do-not-send="true"
 href="mailto:tdwg-content-bounces@lists.tdwg.org">tdwg-content-bounces@lists.tdwg.org</a>
[<a moz-do-not-send="true"
 href="mailto:tdwg-content-bounces@lists.tdwg.org">mailto:tdwg-content-bounces@lists.tdwg.org</a>]
On Behalf Of Bob Morris<br>
Sent: 21 January 2015 15:13<br>
To: John Wieczorek<br>
Cc: TDWG Content Mailing List<br>
Subject: Re: [tdwg-content] Darwin Core Standard - proposed change in
governance<br>
        <br>
John et al. Thanks for all the work you've put into this<br>
        <br>
I favored this at first, but thought a lot since it was proposed and
now oppose item 1).<br>
        <br>
Short argument: RDF is meant for machines to read, not humans to read.<br>
If an RDF document is normative, mainly RDF experts will be able to
argue about it and about  conformance to it.<br>
        <br>
More(?) important, RDF is a graph definition language, not a
specification definition language. Not even RDF  has an RDF file as its
normative definition. In fact, it seems both W3C and IETF regard most
(all?) of their normative artifacts for specification (respectively
"Recommendation" and "Request For Comment") as nothing other than human
readable documents.<br>
        <br>
This is not to say there should not be one or more normative RDFS
serializations of a human readable specification.  It may even be that
there should be a privileged RDFS document, together with a privileged
transformation (e.g. in xslt) and a privileged platform for
synthesizing a human readable form of DwC. But it's that web document
that should be normative (and human readable.)  This is what Audubon
Core does, except that the base "generation data" comprises,
annoyingly, but robustly, calls to the MediaWiki template language.<br>
(The annoyance of designing MediaWiki templates may ease in the future
due to [1])<br>
        <br>
Certainly there are exceptions to the principle of "make only human
readable as the base normative artifact". The XML schemaSchema [2] is
an in example.  But DwC doesn't seem to fit that model. DwC is not a
DwC object.<br>
        <br>
My position is a little influenced by [3], a lot of with which I
disagree. But it reminds me of something my Daddy taught me:<br>
"multi-purpose tools are often poor at all their purposes, except in
simple cases." But really, my reluctance here is that I see no reason
we should imagine that DwC data is always a graph and that is why we
should model it with a graph description language.  Worse, my
experience is that the most common potholes in the RDF world arise when
using it without understanding the underlying graph theory.<br>
        <br>
Bob Morris<br>
        <br>
[1] <a moz-do-not-send="true"
 href="http://www.mediawiki.org/wiki/Lua_scripting">http://www.mediawiki.org/wiki/Lua_scripting</a><br>
[2] <a moz-do-not-send="true"
 href="http://www.w3.org/TR/xmlschema11-1/#normative-schemaSchema">http://www.w3.org/TR/xmlschema11-1/#normative-schemaSchema</a><br>
[3] <a moz-do-not-send="true"
 href="http://manu.sporny.org/2014/json-ld-origins-2/">http://manu.sporny.org/2014/json-ld-origins-2/</a><br>
        <br>
On Tue, Jan 20, 2015 at 10:18 AM, John Wieczorek &lt;<a
 moz-do-not-send="true" href="mailto:tuco@berkeley.edu">tuco@berkeley.edu</a>&gt;
wrote:<br>
        <blockquote type="cite">Dear all,<br>
          <br>
Peter Desmet, Markus Döring, and I have been working on the transition<br>
of Darwin Core maintenance from the Google Code Site to Github. We've<br>
taken the opportunity to streamline the process of making updates to<br>
the standard when they are ratified, such as scripts to produce the<br>
human-readable content and auxiliary files from the RDF document of<br>
current terms. As a result of this work, we see further opportunities<br>
to simplify the maintenance of the standard. They center on the
following proposal.<br>
          <br>
We would like to propose that the RDF document of current terms be<br>
made to represent the normative standard for Darwin Core rather than<br>
Complete History normative document we use now. We would also like to<br>
make that new normative document the only document in the standard.<br>
          <br>
Under this proposal:<br>
          <br>
1) the normative standard for Darwin Core would consist of a single<br>
document at <a moz-do-not-send="true"
 href="http://rs.tdwg.org/terms/dwc_normative.rdf">http://rs.tdwg.org/terms/dwc_normative.rdf</a>
(not currently active).<br>
          <br>
          <br>
2) information currently held in<br>
          <a moz-do-not-send="true"
 href="http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf">http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf</a>
(the current normative<br>
document) and the corresponding Complete History web page<br>
(<a moz-do-not-send="true"
 href="http://rs.tdwg.org/dwc/terms/history/index.htm">http://rs.tdwg.org/dwc/terms/history/index.htm</a>)
would be retained<br>
only in a history document <a moz-do-not-send="true"
 href="http://rs.tdwg.org/terms/history.html">http://rs.tdwg.org/terms/history.html</a>
(not<br>
currently active).<br>
          <br>
          <br>
3) all documents other than the proposed normative document would not<br>
be part of the standard.<br>
          <br>
          <br>
The proposed changes require community consensus under the existing<br>
rules of governance of the Darwin Core. This means that the proposal<br>
must be under public review for at least 30 days after an apparent<br>
consensus on the proposal and any amendments to it is reached, where<br>
consensus consists of no publicly-shared opposition.<br>
          <br>
          <br>
The implications of this proposal are many. One of the most important<br>
is that the rules governing changes to the standard<br>
(<a moz-do-not-send="true"
 href="http://rs.tdwg.org/dwc/terms/namespace/index.htm">http://rs.tdwg.org/dwc/terms/namespace/index.htm</a>)
would no longer be<br>
a part of the standard. Instead, we would promote the adoption of<br>
these rules across TDWG standards rather than just within Darwin Core.<br>
It may be that TDWG is not ready to accommodate this at the moment. If<br>
so, the Namespace Policy could remain within the Darwin Core standard<br>
until the broader governance process for TDWG can cover it, at which<br>
point we would propose to remove the Namespace Policy from the Darwin
Core.<br>
          <br>
          <br>
Other comments about the proposed changes:<br>
          <br>
          <br>
Having one RDF document for the terms in the dwc namespace will avoid<br>
confusion. Only those with status 'recommended' would be in the<br>
normative document.<br>
          <br>
          <br>
Having the term history (all versions, including deprecated,<br>
superseded, and recommended ones) in a web page only is what Dublin<br>
Core does. It means no one would be able to reason over old versions<br>
of the Darwin Core. Would anyone do that?<br>
          <br>
          <br>
Having no document other than the normative one as part of the<br>
standard would free the whole rest of the body of Darwin Core<br>
documentation from the requirements of public review and Executive<br>
Committee approval. This would make that documentation much more open<br>
to broader contributions and easier to adapt to evolving demands.<br>
          <br>
          <br>
We do not propose to lose any of the documentation we have.<br>
          <br>
          <br>
Please share your comments!<br>
          <br>
          <br>
Cheers,<br>
          <br>
          <br>
John<br>
          <br>
          <br>
_______________________________________________<br>
tdwg-content mailing list<br>
          <a moz-do-not-send="true"
 href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
          <br>
        </blockquote>
        <br>
        <br>
        <br>
--<br>
Robert A. Morris<br>
        <br>
Emeritus Professor  of Computer Science<br>
UMASS-Boston<br>
100 Morrissey Blvd<br>
Boston, MA 02125-3390<br>
        <br>
        <br>
Filtered Push Project<br>
Harvard University Herbaria<br>
Harvard University<br>
        <br>
email: <a moz-do-not-send="true" href="mailto:morris.bob@gmail.com">morris.bob@gmail.com</a><br>
web: <a moz-do-not-send="true" href="http://efg.cs.umb.edu/">http://efg.cs.umb.edu/</a><br>
web: <a moz-do-not-send="true" href="http://wiki.filteredpush.org">http://wiki.filteredpush.org</a><br>
      <a moz-do-not-send="true" href="http://wiki.datakurator.net">http://wiki.datakurator.net</a><br>
      <a moz-do-not-send="true" href="http://taxonconceptexplorer.org/">http://taxonconceptexplorer.org/</a><br>
        <a moz-do-not-send="true" href="http://www.cs.umb.edu/%7Eram">http://www.cs.umb.edu/~ram</a><br>
_______________________________________________<br>
tdwg-content mailing list<br>
        <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
        <br>
      </blockquote>
      <br>
      <br>
      <br>
--<span class="Apple-converted-space"> </span><br>
Robert A. Morris<br>
      <br>
Emeritus Professor  of Computer Science<br>
UMASS-Boston<br>
100 Morrissey Blvd<br>
Boston, MA 02125-3390<br>
      <br>
      <br>
Filtered Push Project<br>
Harvard University Herbaria<br>
Harvard University<br>
      <br>
email:<span class="Apple-converted-space"> </span><a
 moz-do-not-send="true" href="mailto:morris.bob@gmail.com">morris.bob@gmail.com</a><br>
web:<span class="Apple-converted-space"> </span><a
 moz-do-not-send="true" href="http://efg.cs.umb.edu/">http://efg.cs.umb.edu/</a><br>
web:<span class="Apple-converted-space"> </span><a
 moz-do-not-send="true" href="http://wiki.filteredpush.org/">http://wiki.filteredpush.org</a><br>
      <a moz-do-not-send="true" href="http://wiki.datakurator.net/">http://wiki.datakurator.net</a><br>
      <a moz-do-not-send="true" href="http://taxonconceptexplorer.org/">http://taxonconceptexplorer.org/</a><br>
      <a moz-do-not-send="true" href="http://www.cs.umb.edu/%7Eram">http://www.cs.umb.edu/~ram</a><br>
_______________________________________________<br>
tdwg-content mailing list<br>
      <a moz-do-not-send="true"
 href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
      <a moz-do-not-send="true"
 href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a></div>
    </blockquote>
    </div>
    <br>
    </div>
    </div>
    </div>
  </blockquote>
  <br>
  <pre class="moz-signature" cols="72">-- 
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences

postal mail address:
PMB 351634
Nashville, TN  37235-1634,  U.S.A.

delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235

office: 2128 Stevenson Center
phone: (615) 343-4582,  fax: (615) 322-4942
If you fax, please phone or email so that I will know to look for it.
<a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://vanderbilt.edu/trees">http://vanderbilt.edu/trees</a>

  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences

postal mail address:
PMB 351634
Nashville, TN  37235-1634,  U.S.A.

delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235

office: 2128 Stevenson Center
phone: (615) 343-4582,  fax: (615) 322-4942
If you fax, please phone or email so that I will know to look for it.
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://vanderbilt.edu/trees">http://vanderbilt.edu/trees</a>

</pre>
</body>
</html>