216-WikiData MarkDown Table, Youtube, Podcasts

Is there a way to find the authors behind the scientific names used on iNat?

If you want to do it thru automation your only real option is to look up the taxon number in an external database such as Wikidata and then if needed get identifiers there from other sources (and hope they have an api). Author names are not stored anywhere internal to inat.


MarkDown Table

if you have a small, simple table in a spreadsheet that you want to translate into markdown, you could also just copy it into a post here in the forum. here’s how the forum translates a table:
Update - Yayy!!! Have been able to reproduced your suggested table pisum

i think, really, you’re trying to use a table format to represent 2 lists of the same items for 2 different time periods. you can do this, but i don’t think it’s really the most efficient way to do this.

i think this is what you’re trying to do:

May 2019
Liaison 1.5
Community liaison 0
Monitoring & research 13.75
Sitework* 22.5
Liaison 82.25
Community liaison 1.75
Monitoring & research 239.5
Sitework 320.75

which can be created using this:

|May 2019||
|Community liaison|0|       
|Monitoring & research|13.75|            

|Community liaison|1.75|
|Monitoring & research|239.5|

However, you could do something this instead:

Cost May 2019 YTD
Liaison 1.5 82.25
Community liaison 0 1.75
Monitoring & research 13.75 239.5
Sitework* 22.5 320.75

which would be created using this:

|Cost|May 2019|YTD|
|Community liaison|0|1.75|  
|Monitoring & research|13.75|239.5|    

you could further right justify some of the columns like so:

Cost May 2019 YTD
Liaison 1.5 82.25
Community liaison 0 1.75
Monitoring & research 13.75 239.5
Sitework* 22.5 320.75

by adding colons on the separator row for columns that you want to right-justify:

|Cost|May 2019|YTD|
|Community liaison|0|1.75|  
|Monitoring & research|13.75|239.5|    

EDIT: the text alignment / justification seems to work only in this Forum’s implementation of extended markdown. the main site’s implementation of extended markdown doesn’t seem to handle it.

the hyphen just defines the split between the header row of the table and the body of the table that contains the actual data. you only need one hyphen per column that you’re trying to represent. you define the columns by using the pipes. so a table with 2 columns needs 3 pipes in each row and 2 hyphens in the separator row.

maybe the official markdown specs indicate three --- per column, and you can do that, but just one - per column seems to work for me.

left center right
1 2 3

left center right
1 2 3

I’d recommend not writing Markdown tables manually. Instead, I use a website called “Tables Generator” that allows you to either (A) create a table through inputting data into cells in a WYSIWYG fashion or (B) copy and paste spreadsheet data straight into it. After that, click on the “Generate” and the markdown code is provided for you to copy and paste. Here’s the link: https://www.tablesgenerator.com/markdown_tables

It also works for HTML, MediaWiki, & LaTeX (aahhh! thesis writing flashbacks) formatting.

if you have a small, simple table in a spreadsheet that you want to translate into markdown, you could also just copy it into a post here in the forum. here’s how the forum translates a table:


today yesterday the day before
1 2 4
5 65 3
5 6 7
|today|yesterday|the day before|

Create by dropping into the forum, but then edit that and copy the code for the table to paste into your journal post.yes, when you paste the code into the forum, you don’t need to actually save the forum post. just copy the markdown that the forum generates, and paste it into the main site. you can simply discard the forum post draft afterward.

But are you sure that method meets the iNat code and will always work?

I can’t guarantee that. However, I’d like to point something out:

The feature announcement post here on iNat included this explanatory comment with two links:

We’re supporting most of basic Markdown formatting, plus the tables extension, even though we don’t have buttons for all those things.

Clicking that “tables extension” link brings you to a page which explains the syntax (worth reading) and includes this tip:

Tip: Creating tables with hyphens and pipes can be tedious. To speed up the process, try using the Markdown Tables Generator. Build a table using the graphical interface, and then copy the generated Markdown-formatted text into your file.

… so I’ll let you do the math on that question.

are you taking this from here (https://www.markdownguide.org/extended-syntax/#tables)?

i think you’re looking for a 100% future-proof guarantee from the iNat staff that they can’t provide.

they are not writing their own code to interpret markdown. they are using code that others have written to interpret the markdown syntax. so it’s those other people who are deciding exactly how the markdown will be parsed / interpreted / processed / rendered / etc… (that other code is what i’m calling the parser, interpreter, etc.)

what makes the situation worse is that there is not a single standard in markdown to handle tables, as far as i can tell. for example, these are two different specifications for handling tables:

  1. GFM (Github Flavored Markdown): https://docs.github.com/en/github/writing-on-github/organizing-information-with-tables
  2. PHP Markdown: https://michelf.ca/projects/php-markdown/extra/

… and different folks can write their parsers to handle to whichever specifications they like.

so if, at some point, iNat folks decide to use different parsers to handle the markdown, the new parsers may handle the markdown slightly differently than the original ones. or if markdown standards evolve, and the parsers change to handle the new standards, that may mean that old markdown syntax may no longer be supported in the updated parsers.

note that i’m using parsers (plural) above – because i think iNat uses different parsers in different places. you can already see how fragmented the situation is in iNat. take a look at this syntax for tables (which is just fine according to PHP Markdown but is not proper syntax according to GFM):


the forum interprets it just fine, a journal post in the main site interprets it just fine, but the observation detail page will not translate into a table. i think that’s because the journal page uses one parser and the observation page uses a different parser (because they are written using two different code architectures, i think).

complicating things further, if you add a markdown table to an observation (either in the description or in a comment), and then you look at it in the Android app, the app doesn’t show you a table at all (because the app code uses yet another parser, which i suppose doesn’t handle tables at all). if you pull it up in a browser on the phone, though, it looks fine (because the web on a computer is more or less the same as the web on the phone).

that said, i would suspect that as markdown standards evolve, the GFM syntax:


… will probably end up being the most well-supported (a de facto standard), if it doesn’t end up being the standard altogether (just because it’s so commonly used). so if you want the most future-proof markdown syntax, i think that’s it right there. (but, again, i doubt that anyone will guarantee that syntax to be 100% future-proof.)

however, i would suspect that most parsers of the future – and even now – will also support:


Youtube, Podcasts

Het programma is een beetje geïnspireerd op de creatieve uitvinderscultuur die je ziet op YouTubekanalen als Queen of Shitty Robots [van Simone Giertz, red.] of dat van Mark Rober. Ik hoop dat we vooral de luchtige kant van wetenschap kunnen overbrengen, want mensen ervaren wetenschap nog te vaak als elitair en ingewikkeld. In Anna’s Brains zie je hopelijk dat wetenschap er ook voor jouw plezier is en ook jouw vragen kan beantwoorden. Zonder hoge piefen die je de les proberen te lezen, want onze Brains zijn gewoon leuke jonge wetenschappers – en een paar wat oudere techneuten – die lol maken. De Brains en ik zitten op dezelfde golflengte, omdat we allemaal nerds zijn die wetenschap gebruiken om leuke dingen te doen: grappige experimenten en dingen waar je gewoon benieuwd naar bent. Zo van: kijken of het lukt! Heel erg trial- and-error dus; het programma heette eerst ook Trial & Anna.’


Verder schreven onze natuurvrienden elk vanuit
hun eigen perspectief, maar allemaal met liefde voor
natuur over onder andere pingoruïnes, levende en
dode beesten, skeletten, papiervisjes, zintuigen van
vogels, grote wederik & slobkousbij en kerkuilen. De
quiz behandelt goudgele kroonjuwelen en een aantal
natuurpodcasts staan op een rij. Eunice Mollema
presenteert deze keer geen spinnen, maar haar prachtige

Groene Oren van Staatsbosbeheer
Hiër vërtëllën plantën, bomën ën diërën zélf hun vërhaal: wië zijn zë, hoë ziët hun
dagëlijks lëvën ër uit ën hoë is hët om vanuit hun përspëctiëf dë wërëld të ërvarën?
Tip: Paulien de Eik
ANWB De Buitendienst
Gëniët ëën uur lang van zingëndë vogëls, zoëmëndë insëctën
ën ritsëlëndë bladërën. Hët is alsof jë ër zëlf middënin zit.
Tip: 4 Seizoenen op het Deelense Veld

Puur Natuur van Natuurmonumenten
Puur Natuur lëërt jë mëër ovër dë afwissëlëndë natuur in ons land.
Tip: Rick Huis in ’t Veld over de natuur op zijn biologische boerderij
Vroege Vogels en andere dieren
Bioloog Aukë-Florian Hiëmstra van Naturalis ën Vroëgë Vogël Annëkë Naafs gaan
ëlkë wëëk op zoëk naar ëën bijzondër diër ën willën daar állës van wëtën.
Tip: Aflevering 2 – Waarom de regenworm het meest charismatische dier op aarde is!
Roots Natuurpodcast
Hiër bijvoorbëëld dë sërië Notënkrakërs – waarin iëdërë këër één vogëlsoort in
dë spotlights staat.
Tip: de boerenzwaluw maakt het geluid van de zomer
Hëb jë ëën lëuk ondërwërp of tips voor dëzë rubriëk? Suggëstiës zijn van hartë wëlkom!
Mail zë ondër vërmëlding van ‘Natuur digitaal’ naar ivngroningen.redactiegroeningen@gmail

Humberto Tan, VogelPodcast

由使用者 ahospers ahospers2021年08月30日 21:18 所貼文




登入註冊 添加評論