<div align="left"><p dir="ltr">typeshed, dotted lookup, ScholarlyArticle semantic graphs with classes, properties, and URIs</p><p dir="ltr">
Would external metadata (similar to how typeshed is defined in a 'shadow naming scheme' (?)) be advantageous<br>
for dotted name lookup of citation metadata?</p>
<p dir="ltr">> Typeshed contains external type annotations for the Python standard library and Python builtins, as well as third party packages.<br>
><br>
</p>
</div><div align="left"><p dir="ltr">> This data can e.g. be used for static analysis, type checking or type inference.</p>
<p dir="ltr"><a href="https://github.com/python/typeshed">https://github.com/python/typeshed</a><br>
stdlib/{2, 2and3, 3, 3.5, 3.6, 3.7}<br>
third_party/{2, 2and3, 3}/{jinja2,}</p>
<p dir="ltr">Ideally, a ScholarlyArticle can also be published as HTML with RDFa and/or JSONLD (in addition to two column LaTeX/PDF which is lossy in regards to structured data / linked data) with its own document-level metadata simply as part of a graph of resources (such as schema:citation and schema:Datasets) described using a search-indexed vocabulary such as the Schema.org RDFS vocabulary.</p>
<p dir="ltr">An aside:<br>
<a href="https://schema.org/unitCode">https://schema.org/unitCode</a> has a range of {Text, URL} where the Text should be a 3 character UN/CEFACT Common Code; but there's also QUDT for unit URIs; fortunately, RDF allows repeated property values, so we can just add both.</p></div><br>On Wednesday, July 4, 2018, Wes Turner <<a href="mailto:wes.turner@gmail.com">wes.turner@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">... a schema:Dataset may be part of a Creative work.<div><br></div><div><a href="https://schema.org/Dataset" target="_blank">https://schema.org/Dataset</a></div><div><a href="https://schema.org/isPartOf" target="_blank">https://schema.org/isPartOf</a></div><div><a href="https://schema.org/ScholarlyArticle" target="_blank">https://schema.org/<wbr>ScholarlyArticle</a></div><div><br></div><div>#LinkedReproducibility #nbmeta<br><br>On Wednesday, July 4, 2018, Wes Turner <<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><a href="https://schema.org/CreativeWork" target="_blank">https://schema.org/CreativeWor<wbr>k</a></div><div>  <a href="https://schema.org/Code" target="_blank">https://schema.org/Code</a></div><div>  <a href="https://schema.org/SoftwareApplication" target="_blank">https://schema.org/SoftwareApp<wbr>lication</a></div><div><br></div><div>CreativeWork has a <a href="https://schema.org/citation" target="_blank">https://schema.org/citation</a> field with a range of {CreativeWork, Text}</div><div><br></div><div>There's also a <a href="https://schema.org/funder" target="_blank">https://schema.org/funder</a> attribute with a domain of CreativeWork and a range of {Organization, Person}</div><div><br></div><div>- BibTeX is actually somewhat ill-specified, TBH.</div><div>- There is a repository of CSL styles at <a href="https://citationstyles.org" target="_blank">https://citationstyles.org</a> .</div><div>- CSL is sponsored by both Zotero and Mendeley.</div><div>- A number of search engines support <a href="http://schema.org" target="_blank">schema.org</a> (and JSONLD)</div><div>- The <a href="http://schema.org" target="_blank">schema.org</a> RDFS vocabulary is designed to describe a graph of resources (CreativeWork, Code, SoftwareApplication, ScholarlyArticle, MedicalScholarlyArticle).</div><div><br></div><div>__citation__ = [{}, ]</div><div>__citation__ = {</div><div>  '@type': ['schema:ScholarlyArticle'],</div><div>  'schema:name': '',</div><div>  'schema:author': [{</div><div>      '@type': 'schema:Person',</div><div>      '...': '...'}]</div><div>}</div><div><br></div><div>JSONLD is ideal for describing a graph of resources with varied types.</div><div><br></div><div>If the overhead of __citation__ for every import is unjustified,</div><div>a lookup of methods with dotted names that finds entries for root modules as well would be great:</div><div><br></div><div>>>> citations('json.loads')</div><div>>>> citations('list.sort')</div><div><br></div><div>A tracing debugger could lookup each and every package, module, function, and method each ScholarlyArticle SoftwareApplication executes (from a registry in e.g. a _citations_.py or a _citations_.jsonld.json).</div><div><br></div><div>It'd be a shame to need to manually format citations for a particular Journal's CSL bibliographic  metadata template preference.</div><div><br></div><div>sphinxcontrib-bibtex is a Sphinx extension for BibTeX support (with a bibliography directive and a cite role)</div><div>- Src: <a href="https://github.com/mcmtroffaes/sphinxcontrib-bibtex" target="_blank">https://github.com/mcmtroffaes<wbr>/sphinxcontrib-bibtex</a></div><div><br></div><div>Jupyter notebooks support document-level metadata (in JSON that's currently only similar to <a href="http://schema.org" target="_blank">schema.org</a> JSONLD).</div><div><br></div><div><div><a href="https://schema.org/ScholarlyArticle" target="_blank">https://schema.org/ScholarlyAr<wbr>ticle</a> is search engine indexable.</div></div><div><br></div><br>On Wednesday, July 4, 2018, Alexander Belopolsky <<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@gmail.co<wbr>m</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 1, 2018 at 9:45 AM David Mertz <<a href="mailto:mertz@gnosis.cx" target="_blank">mertz@gnosis.cx</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>..</div><div dir="auto">There's absolutely nothing in the idea that requires a change in Python, and Python developers or users are not, as such, the relevant experts.</div></div></blockquote><div><br></div><div>This is not entirely true.  If some variant of __citation__ is endorsed by the community, I would expect that pydoc would extract this information to fill an appropriate section in the documentation page.  Note that pydoc already treats a number of dunder variables specially: '__author__', '__cr<wbr>edits__', and '__version__' are a few that come to mind, so I don't think the threshold for adding one more should be too high.  On the other hand, maybe  <span style="background-color:rgb(255,255,255);float:none;display:inline"> '__author__', '__credi<wbr>ts__', and '__citation__' should be merged in one structured variable (a dict?) with format designed with some extendability in mind.</span></div></div></div>
</blockquote>
</blockquote></div>
</blockquote>