-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Kyle Braak
committed
May 10, 2016
1 parent
f9c6f1f
commit 254aea0
Showing
1 changed file
with
33 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| <?xml version="1.0" encoding="UTF-8"?> | ||
| <?xml-stylesheet type="text/xsl" href="/style/human.xsl"?> | ||
| <extension xmlns="http://rs.gbif.org/extension/" | ||
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | ||
| xmlns:dc="http://purl.org/dc/terms/" | ||
| xsi:schemaLocation="http://rs.gbif.org/extension/ http://rs.gbif.org/schema/extension.xsd" | ||
| dc:title="GBIF Relevé" | ||
| name="Releve" namespace="http://rs.gbif.org/terms/1.0/" rowType="http://rs.gbif.org/terms/1.0/Releve" | ||
| dc:issued="2016-05-10" | ||
| dc:subject="dwc:Event" | ||
| dc:relation="http://rs.gbif.org/sandbox/extension/releve.xml" | ||
| dc:description="Support for vegetation plot survey (relevé) measurements ancillary to those reported using Event core with Occurrence extension."> | ||
| <property name='project' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/project' dc:relation='' dc:description='The name or code for the project associated with the relevé' examples='"Project Bos-Eco-Systemen"' required='false'/> | ||
| <property name='syntaxonName' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/syntaxonName' dc:relation='http://www.iavs.org/pdf/Code.pdf' dc:description='The description (not a code) of the plant community or vegetation unit associated with the relevé' examples='"Littorelletea", "Luzulo-Fagetum Meusel 1937"' required='false'/> | ||
| <property name='aspect' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/aspect' dc:relation='' dc:description='The compass direction that the relevé site faces' thesaurus="http://rs.gbif.org/vocabulary/gbif/direction.xml" examples='"N", "NE", "NNE"' required='false'/> | ||
| <property name='inclinationInDegrees' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/inclinationInDegrees' dc:relation='' dc:description='The angle of inclination of the relevé site in degrees, rounded to the nearest whole number' examples='"40"' required='false'/> | ||
| <property name='coverTotalInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverTotalInPercentage' dc:relation='' dc:description='The total cover (%) of all plants, rounded to the nearest whole number' examples='"99"' required='false'/> | ||
| <property name='coverTreesInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverTreesInPercentage' dc:relation='' dc:description='The cover (%) of trees, rounded to the nearest whole number' examples='"70"' required='false'/> | ||
| <property name='coverShrubsInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverShrubsInPercentage' dc:relation='' dc:description='The cover (%) of shrubs, rounded to the nearest whole number' examples='"50"' required='false'/> | ||
| <property name='coverHerbsInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverHerbsInPercentage' dc:relation='' dc:description='The cover (%) of the herb layer, rounded to the nearest whole number' examples='"15"' required='false'/> | ||
| <property name='coverCryptogamsInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverCryptogamsInPercentage' dc:relation='' dc:description='The cover (%) of cryptogams, rounded to the nearest whole number.' examples='"150"' required='false'/> | ||
| <property name='coverMossesInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverMossesInPercentage' dc:relation='' dc:description='The cover (%) of mosses, rounded to the nearest whole number' examples='"10"' required='false'/> | ||
| <property name='coverLichensInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverLichensInPercentage' dc:relation='' dc:description='The cover (%) of lichens, rounded to the nearest whole number' examples='"99"' required='false'/> | ||
| <property name='coverAlgaeInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverAlgaeInPercentage' dc:relation='' dc:description='The cover (%) of algae, rounded to the nearest whole number' examples='"1"' required='false'/> | ||
| <property name='coverLitterInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverLitterInPercentage' dc:relation='' dc:description='The cover (%) of litter, rounded to the nearest whole number' examples='"65"' required='false'/> | ||
| <property name='coverWaterInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverWaterInPercentage' dc:relation='' dc:description='The cover (%) of open water, rounded to the nearest whole number' examples='"25"' required='false'/> | ||
| <property name='coverRockInPercentage' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/coverRockInPercentage' dc:relation='' dc:description='The cover (%) of bare rock, rounded to the nearest whole number' examples='"55"' required='false'/> | ||
| <property name='treeLayerHeightInMeters' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/treeLayerHeightInMeters' dc:relation='' dc:description='The height in meters of the tree layer, rounded to the nearest whole number' examples='"19"' required='false'/> | ||
| <property name='shrubLayerHeightInMeters' type='decimal' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/shrubLayerHeightInMeters' dc:relation='' dc:description='The height in meters of the shrub layer, can be written in decimal notation' examples='"2.1"' required='false'/> | ||
| <property name='herbLayerHeightInCentimeters' type='integer' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/herbLayerHeightInCentimeters' dc:relation='' dc:description='The height in centimeters of the high herb layer, rounded to the nearest whole number' examples='"25"' required='false'/> | ||
| <property name='mossesIdentified' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/mossesIdentified' dc:relation='' dc:description='The value is true if mosses in the releve were identified' thesaurus="http://rs.gbif.org/vocabulary/basic/boolean.xml" examples='"True" "False", or left empty if unknown' required='false'/> | ||
| <property name='lichensIdentified' namespace='http://rs.gbif.org/terms/1.0/' qualName='http://rs.gbif.org/terms/1.0/lichensIdentified' dc:relation='' dc:description='The value is true if lichens in the releve were identified' thesaurus="http://rs.gbif.org/vocabulary/basic/boolean.xml" examples='"True" "False", or left empty if unknown' required='false'/> | ||
| </extension> |
254aea0There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is different from the previous version issued 2016-02-26 in the following ways:
254aea0There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should not version sandbox files, being in flux is the whole point of the sandbox
254aea0There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Versioning extensions in the sandbox is a matter of personal preference, however, I would highly recommend doing it because this allows the extensions to be easily upgraded in the test mode IPT.
Had I not versioned this extension, I'd have to delete all mappings to it (for all resources), uninstall it, and install it again. This is a hassle, especially if lots of resources have mappings to the extension. For everyone's benefit, some screenshots are attached showing how the extension looks pre and post update.
254aea0There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't it be better if the IPT would allow to upgrade all extensions when in sandbox mode from the same URL? It could test the created date or just do a file hashing to see if anything has changed. It could even check if a term was added, deleted or renamed to modify mappings. All other changes (descriptions, links, etc) could probably be just incorporated without touching a resource.
254aea0There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that adding a version date in the file name is something imposed by the IPT, rather than something we want. I find that the version dates in the files actually work against git: I can't easily compare changes (e.g. coverScale being removed), I can't easily suggest changes via PR and it's harder to review PR. Also, with all the versions still around, I have to read all the dates to see which one is the most recent one.
Wouldn't it be possible to have system where the versioning is done in git and that the file itself (not the file name) contains a version number. I would actually prefer this for non-sandbox vocabs, extensions, etc. too.
254aea0There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I definitely understand where you are coming from but sadly no - they both need to be accessible on URLs at the same time. For robustness sake I think we would be unwise to introduce resolution services in front of these files. I would suggest not fixing this in this iteration of work - I doubt we could now anyway, given these things are out there and IPT 2.3.x's rely on this being available.
Rather, I suggest we consider it in the design for the management of vocabularies and data structures in the W3C CSV data packaging (e.g. what we hope to progress in TDWG conf 2016 and implement in 2017) which will replace all of this. That will likely allow for a complete rewrite of the formats and management procedures based on what we have learnt, and should be in a standard vocabulary flavour (SKOS, yaml or whatever it is that we settle upon) and not in an adhoc XML schema that we've invented in relative isolation.
254aea0There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah... you're right. 😢 We'll then probably have to keep the current implementation around for a while, to support legacy systems.