<div dir="ltr">Dear all,<div><br></div><div>There seems to be some consensus forming that simplification is good, and that the history should be part of the normative document.</div><div><br></div><div>Without committing to a stance on RDF versus anything else as a normative document, we (Markus, actually) have made scripts to produce the human readable version from the RDF so that the two will be easy to synchronize. In fact, the script generates several documents to keep everything in sync. </div><div><br></div><div>Right now that human-readable version is similar to the present standard Quick Reference Guide (<a href="http://rs.tdwg.org/dwc/terms/index.htm">http://rs.tdwg.org/dwc/terms/index.htm</a>), with very little explanation aside from the terms, and only a few of the properties for the terms. If we have a normative document, then it must contain all of the properties of the terms, as in the present Complete History document (<a href="http://rs.tdwg.org/dwc/terms/history/index.htm">http://rs.tdwg.org/dwc/terms/history/index.htm</a>). There is more in those term definitions than most people need. So, if we go with a human-readable document (HTML?), it should contain as little explanatory text that could change over time as possible. I also suggest that we should have an even more prominent human-readable page that has only what most people need (a la the Quick Reference Guide). Every derived document (Quick Reference, RDF document, XML schemas, terms list, term pages on the GBIF Media Wiki) should have a reference to the normative document, and they should absolutely be kept in sync with the normative document. <div><br></div><div>Is this a sound alternative proposal?</div></div><div><br></div><div>Do I get the sense that for now the standard should retain the Namespace Policy, until TDWG can set up a broader policy?</div><div><br></div><div>Cheers,</div><div><br></div><div>John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 4:59 PM, Bertram Ludaescher <span dir="ltr"><<a href="mailto:ludaesch@gmail.com" target="_blank">ludaesch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>+1 for "human readable"<br></div><div><br></div><div>(last time I checked, humans were still doing most of the thinking on planet Earth :)<br></div><div><br></div><div>Oh and "parsers" were one of the first things computer scientists invented to make human-readable things also machine-readable. I think they still make those ;-)</div><div><br></div><div>Over the years, we might have gone overboard with "one size fits all" (XML, RDF, <insert your favorite language here> ... )</div><div><br></div><div>My 2 cents..</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Bertram</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 9:49 AM, Éamonn Ó Tuama [GBIF] <span dir="ltr"><<a href="mailto:eotuama@gbif.org" target="_blank">eotuama@gbif.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 href="http://www.w3.org/TR/vocab-dcat/" target="_blank">http://www.w3.org/TR/vocab-dcat/</a><br>
<div><div><br>
-----Original Message-----<br>
From: <a href="mailto:tdwg-content-bounces@lists.tdwg.org" target="_blank">tdwg-content-bounces@lists.tdwg.org</a> [mailto:<a href="mailto:tdwg-content-bounces@lists.tdwg.org" target="_blank">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 href="http://www.mediawiki.org/wiki/Lua_scripting" target="_blank">http://www.mediawiki.org/wiki/Lua_scripting</a><br>
[2] <a href="http://www.w3.org/TR/xmlschema11-1/#normative-schemaSchema" target="_blank">http://www.w3.org/TR/xmlschema11-1/#normative-schemaSchema</a><br>
[3] <a href="http://manu.sporny.org/2014/json-ld-origins-2/" target="_blank">http://manu.sporny.org/2014/json-ld-origins-2/</a><br>
<br>
On Tue, Jan 20, 2015 at 10:18 AM, John Wieczorek <<a href="mailto:tuco@berkeley.edu" target="_blank">tuco@berkeley.edu</a>> wrote:<br>
> 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 href="http://rs.tdwg.org/terms/dwc_normative.rdf" target="_blank">http://rs.tdwg.org/terms/dwc_normative.rdf</a> (not currently active).<br>
><br>
><br>
> 2) information currently held in<br>
> <a href="http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf" target="_blank">http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf</a> (the current normative<br>
> document) and the corresponding Complete History web page<br>
> (<a href="http://rs.tdwg.org/dwc/terms/history/index.htm" target="_blank">http://rs.tdwg.org/dwc/terms/history/index.htm</a>) would be retained<br>
> only in a history document <a href="http://rs.tdwg.org/terms/history.html" target="_blank">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 href="http://rs.tdwg.org/dwc/terms/namespace/index.htm" target="_blank">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 href="mailto:tdwg-content@lists.tdwg.org" target="_blank">tdwg-content@lists.tdwg.org</a><br>
> <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
><br>
<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 href="mailto:morris.bob@gmail.com" target="_blank">morris.bob@gmail.com</a><br>
web: <a href="http://efg.cs.umb.edu/" target="_blank">http://efg.cs.umb.edu/</a><br>
web: <a href="http://wiki.filteredpush.org" target="_blank">http://wiki.filteredpush.org</a><br>
<a href="http://wiki.datakurator.net" target="_blank">http://wiki.datakurator.net</a><br>
<a href="http://taxonconceptexplorer.org/" target="_blank">http://taxonconceptexplorer.org/</a><br>
<a href="http://www.cs.umb.edu/~ram" target="_blank">http://www.cs.umb.edu/~ram</a><br>
_______________________________________________<br>
tdwg-content mailing list<br>
<a href="mailto:tdwg-content@lists.tdwg.org" target="_blank">tdwg-content@lists.tdwg.org</a><br>
<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
<br>
_______________________________________________<br>
tdwg-content mailing list<br>
<a href="mailto:tdwg-content@lists.tdwg.org" target="_blank">tdwg-content@lists.tdwg.org</a><br>
<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>