<p dir="ltr"></p>
<p dir="ltr">On Jul 19, 2016 8:44 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> On 19 July 2016 at 18:13, Wes Turner <<a href="mailto:wes.turner@gmail.com">wes.turner@gmail.com</a>> wrote:<br>
> > so, there's a need for specifying the {PyPI} package URI in setup.py<br>
><br>
> Not really - tools can make a reasonable guess about the source PyPI<br>
> URL based purely on the name and version. For non-PyPI hosted<br>
> packages, the extra piece of info needed is the index server URL.</p>
<p dir="ltr">So, the index server URL is in pip.conf or <br>
.pydistutils.cfg or setup.cfg OR specified on the commandline?</p>
<p dir="ltr">><br>
> > and then generating meta.jsonld from setup.py<br>
><br>
> No, a JSON-LD generator would start with a rendered metadata format,<br>
> not the raw setup.py.</p>
<p dir="ltr">"pydist.json", my mistake</p>
<p dir="ltr"><a href="https://github.com/pypa/interoperability-peps/issues/31#issuecomment-139657247">https://github.com/pypa/interoperability-peps/issues/31#issuecomment-139657247</a><br>
- pydist.json<br>
- metadata.json (wheel)</p>
<p dir="ltr">- pydist.jsonld</p>
<p dir="ltr">><br>
> > and then generating JSONLD in a warehouse/pypa view; because that's where<br>
> > they keep the actual metadara (package platform versions, checksums,<br>
> > potentially supersededBy redirects)<br>
><br>
> No, there is no requirement for this to be a PyPI feature. Absolutely none.<br>
><br>
> > and then a signing key for a) package maintainer-supplied metadata and b)<br>
> > package repository metadata (which is/would be redundant but comforting)<br>
><br>
> This is already covered (thoroughly) in PEPs 458 and 480, and has<br>
> nothing to do with metadata linking.</p>
<p dir="ltr">ld-signatures can be used to sign {RDF, JSONLD, RDFa}; and attach the signature to the document.</p>
<p dir="ltr"><a href="https://web-payments.org/specs/source/ld-signatures/">https://web-payments.org/specs/source/ld-signatures/</a></p>
<p dir="ltr">- JWS only works with JSON formats (and not RDF)</p>
<p dir="ltr"><a href="https://www.python.org/dev/peps/pep-0480/">https://www.python.org/dev/peps/pep-0480/</a></p>
<p dir="ltr">- Does this yet include signing potentially cached JSON metadata used by actual tools like e.g. pip?<br>
- How do you feel about redirects because superseded and nobody can convince the maintainer to update the long_description?</p>
<p dir="ltr">><br>
> > and then third-party services like NVD, CVEdetails, and stack metadata<br>
> > aggregation services<br>
><br>
> And this is the other reason why it doesn't make sense to do this on<br>
> PyPI itself - the publisher provided metadata from PyPI is only one<br>
> piece of the project metadata puzzle (issue trackers and source code<br>
> repositories are another one, as are the communication metrics<br>
> collected by the likes of Bitergia).</p>
<p dir="ltr">AFAIU, the extra load of fielding vulnerability reports for responsibly PyPI-hosted packages is beyond the scope of the PyPI and Warehouse packages.</p>
<p dir="ltr">><br>
> For a data aggregator, supporting multiple language ecosystems, and<br>
> multiple issue trackers, and multiple code hosting sites is an M+N+O<br>
> scale problem (where M is the number of language ecosystems supported,<br>
> etc). By contrast, if you try to solve this problem in the package<br>
> publication services for each individual language, you turn it into an<br>
> M*(N+O) scale problem, where you need to give each language-specific<br>
> service the ability to collect metadata from all those other sources.</p>
<p dir="ltr">Are you saying that, for <a href="http://release-monitoring.org">release-monitoring.org</a> (a service you are somehow financially associated with), you have already invested the time to read the existing PyPI metadata; but not eg the 'python' or 'python-dev' OS package metadata?</p>
<p dir="ltr">Debian has an RDF endpoint.<br>
- <a href="https://packages.qa.debian.org/p/python-defaults.html">https://packages.qa.debian.org/p/python-defaults.html</a><br>
- <br>
<a href="https://packages.qa.debian.org/p/python-defaults.ttl">https://packages.qa.debian.org/p/python-defaults.ttl</a><br>
- But there's yet no easy way to JOIN metadata down the graph of  downstream OS packages to PyPI archives to source repository changesets;<br>
not without RDF <br>
and not without writing unnecessary language/packaging-community-specific {INI,JSON,TOML,  YAMLLD  } parsers.</p>
<p dir="ltr">O-estimations aside,<br>
when a data publisher publishes web standard data,<br>
everyone can benefit;<br>
because upper bound network effects N**2 (Metcalf's Law)</p>
<p dir="ltr">><br>
> This means that since we don't have a vested interest in adding more<br>
> functionality to PyPI that doesn't specifically *need* to be there<br>
> (and in fact actively want to avoid doing so), we can say "Conformance<br>
> to semantic web standards is a problem for aggregation services like<br>
> <a href="http://libraries.io">libraries.io</a> and <a href="http://release-monitoring.org">release-monitoring.org</a> to solve, not for us to<br>
> incorporate directly into PyPI".</p>
<p dir="ltr">A view producing JSONLD.</p>
<p dir="ltr">Probably right about here:<br>
<a href="https://github.com/pypa/warehouse/blob/master/warehouse/packaging/views.py">https://github.com/pypa/warehouse/blob/master/warehouse/packaging/views.py</a></p>
<p dir="ltr">Because there are a few (possibly backwards compatible) changes that could be made here so that we could just add @context to the existing JSON record (thus making it JSONLD, which anyone can read and index without a domain-specific parser):<br>
<a href="https://github.com/pypa/warehouse/blob/master/warehouse/legacy/api/json.py">https://github.com/pypa/warehouse/blob/master/warehouse/legacy/api/json.py</a></p>
<p dir="ltr">IIRC: <br>
<a href="https://github.com/pypa/interoperability-peps/issues/31#issuecomment-233195564">https://github.com/pypa/interoperability-peps/issues/31#issuecomment-233195564</a></p>
<p dir="ltr">><br>
> > sorry to hijack the thread;  i hear "more links and metadata in an<br>
> > auxilliary schema" and think 'RDF is the semantic web solution for this<br>
> > graph problem'<br>
><br>
> I know, and you're not wrong about that. Where you're running into<br>
> trouble is that you're trying to insist that it is the responsibility<br>
> of the initial data *publishers* to conform to the semantic web<br>
> standards, and it *isn't* - that job is one for the data aggregators<br>
> that have an interest in making it easier for people to work across<br>
> multiple data sets managed by different groups of people.</p>
<p dir="ltr">No, after-the-fact transformation is wasteful and late.</p>
<p dir="ltr">A bit of advice for data publishers:<br>
<a href="http://5stardata.info/en/">http://5stardata.info/en/</a></p>
<p dir="ltr">><br>
> For publication platforms managing a single subgraph, native support<br>
> for JSON-LD and RDFa introduces unwanted complexity by expanding the<br>
> data model to incorporate all of the relational concepts defined in<br>
> those standards. Well funded platforms may have the development<br>
> capacity to spare to spend time on such activities, but PyPI isn't<br>
> such a platform.</p>
<p dir="ltr">This is Warehouse:<br>
<a href="https://github.com/pypa/warehouse">https://github.com/pypa/warehouse</a></p>
<p dir="ltr">It is maintainable.</p>
<p dir="ltr"><a href="https://www.pypa.io/en/latest/help/">https://www.pypa.io/en/latest/help/</a></p>
<p dir="ltr">><br>
> By contrast, for aggregators managing a graph-of-graphs problem,<br>
> JSON-LD and RDFa introduce normalisation across data sets that<br>
> *reduces* overall complexity, since most of the details of the<br>
> subgraphs can be ignored, as you focus instead on the links between<br>
> the entities they contain.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
> --<br>
> Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br></p>