Darwin Core concept name aliases for use in API
Aaron Steele
So we're coming up with short (1-6 characters) alias for each Darwin
Core concept name for use in the API. Why? Because we're lazy
programmers and we don't want to write things like
`coordinateuncertaintyinmeters=100` when we could instead
write`cuim=100`.
For background and context on this, here's the GitHub issue:
https://github.com/VertNet/Software/issues/22
We'd be curious about any feedback you have about these aliases since
they would be part of the search API that we'd all be using. Here's
the full list:
https://gist.github.com/1130903
Thoughts? Changes? Flames?
John Wieczorek
only programmers and their progeny will have to deal with this
optimization.
Aaron Steele
> only programmers and their progeny will have to deal with this
> optimization.
Well, maybe. Pass URLs around to "real humans" who might need to see
the full Darwin Core concept names for clarity is a use case. So maybe
the idea here is that the API will support both full and aliased
names. Good compromise?
John Wieczorek
our human users either way. They aren't likely to go around
constructing queries with raw URLs unless they are forced to. I
wouldn't spend time on it beyond implementing the codes.
Dave Vieglais
Aaron Steele
> our human users either way. They aren't likely to go around
> constructing queries with raw URLs unless they are forced to. I
> wouldn't spend time on it beyond implementing the codes.
Hmmm. Actually, readable URLs are kind of essential to the web? I can
totally see emailing URLs to publishers, curators, and users. It's
much less cryptic for them to read and understand URLs like:
datasetName=Birds&dateIdentified=2008&day=360
instead of:
dn=Birds&di=2008&d=360
Maybe? It's really fast to support full names and abbreviations in the
API, so easy peasy either way.
Aaron Steele
> each record, but I guess it's no sweat for Google - easier for them to not
> deal with an internal hash map, and makes money through more storage.
Well, remember that the Google datastore is a key-value store. There
are actually no columns at all! Apps store data in a schema-less way
(hence the repetition) so there's no need for a fixed data model.
These NoSQL datastores were developed specifically to perform at scale
horizontally. The tradeoff is disk space, true. FWIW, all of the big
open source key values stores are implemented the same way (CouchDB,
Cassandra, MongoDB, et al).
> 2. It might be worth adding abbreviations to the DwC terms, perhaps on the
> quick reference page? That way other implementors will see the abbreviations
> and be less likely to go out and create their own. Even if only used
> internally, consistency will still be useful.
Great idea. John, can we email the Darwin Core lists for some feedback
about canonical concept abbreviations? Maybe we can create quick
reference page with what we have and then send that? In the meantime I
think we can go with what we have for the prototype API and can change
it as once we get feedback.
> 3. Having the abbreviations listed along with the DwC term definitions will
> reduce the need for the URL handling of full names.
See my comments to John above. Easy to support both, and I think there
are compelling reasons to support both, so maybe a non-issue?
Aaron Steele
>> quick reference page? That way other implementors will see the abbreviations
>> and be less likely to go out and create their own. Even if only used
>> internally, consistency will still be useful.
>
> Great idea. John, can we email the Darwin Core lists for some feedback
> about canonical concept abbreviations? Maybe we can create quick
> reference page with what we have and then send that? In the meantime I
> think we can go with what we have for the prototype API and can change
> it as once we get feedback.
Issue submitted for this: https://github.com/VertNet/Software/issues/25