https://schema.org/CreativeWork https://schema.org/Code https://schema.org/SoftwareApplication
CreativeWork has a https://schema.org/citation field with a range of {CreativeWork, Text} There's also a https://schema.org/funder attribute with a domain of CreativeWork and a range of {Organization, Person} - BibTeX is actually somewhat ill-specified, TBH. - There is a repository of CSL styles at https://citationstyles.org . - CSL is sponsored by both Zotero and Mendeley. - A number of search engines support schema.org (and JSONLD) - The schema.org RDFS vocabulary is designed to describe a graph of resources (CreativeWork, Code, SoftwareApplication, ScholarlyArticle, MedicalScholarlyArticle). __citation__ = [{}, ] __citation__ = { '@type': ['schema:ScholarlyArticle'], 'schema:name': '', 'schema:author': [{ '@type': 'schema:Person', '...': '...'}] } JSONLD is ideal for describing a graph of resources with varied types. If the overhead of __citation__ for every import is unjustified, a lookup of methods with dotted names that finds entries for root modules as well would be great: >>> citations('json.loads') >>> citations('list.sort') 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). It'd be a shame to need to manually format citations for a particular Journal's CSL bibliographic metadata template preference. sphinxcontrib-bibtex is a Sphinx extension for BibTeX support (with a bibliography directive and a cite role) - Src: https://github.com/mcmtroffaes/sphinxcontrib-bibtex Jupyter notebooks support document-level metadata (in JSON that's currently only similar to schema.org JSONLD). https://schema.org/ScholarlyArticle is search engine indexable. On Wednesday, July 4, 2018, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > > On Sun, Jul 1, 2018 at 9:45 AM David Mertz <me...@gnosis.cx> wrote: > >> .. >> 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. >> > > 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__', > '__credits__', > 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 '__author__', '__credits__', and '__citation__' should be merged > in one structured variable (a dict?) with format designed with some > extendability in mind. >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
