<p dir="ltr">so, there's a need for specifying the {PyPI} package URI in setup.py</p>
<p dir="ltr">and then generating meta.jsonld from setup.py</p>
<p dir="ltr">and then generating JSONLD in a warehouse/pypa view; because that's where they keep the actual metadara (package platform versions, checksums, potentially supersededBy redirects)</p>
<p dir="ltr">and then a signing key for a) package maintainer-supplied metadata and b) package repository metadata (which is/would be redundant but comforting)</p>
<p dir="ltr">and then third-party services like NVD, CVEdetails, and stack metadata aggregation services</p>
<p dir="ltr">- "PEP 426: Define a JSON-LD context as part of the proposal"<br>
  <a href="https://github.com/pypa/interoperability-peps/issues/31">https://github.com/pypa/interoperability-peps/issues/31</a><br>
- "Expressing dependencies (between data, software, content...)"<br>
  <a href="https://github.com/schemaorg/schemaorg/issues/975">https://github.com/schemaorg/schemaorg/issues/975</a></p>
<p dir="ltr">sorry to hijack the thread;  i hear "more links and metadata in an auxilliary schema" and think 'RDF is the semantic web solution for this graph problem'</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Jul 19, 2016 3:59 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 19 July 2016 at 17:25, Wes Turner <<a href="mailto:wes.turner@gmail.com">wes.turner@gmail.com</a>> wrote:<br>
> On Jul 19, 2016 2:37 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> Given that we already have services like <a href="http://libraries.io" rel="noreferrer" target="_blank">libraries.io</a> and<br>
>> <a href="http://release-monitoring.org" rel="noreferrer" target="_blank">release-monitoring.org</a> for ecosystem independent tracking of upstream<br>
>> releases, they're more appropriate projects to target for the addition<br>
>> of semantic linking support to project metadata, as having one or two<br>
>> public semantic linking projects like that for the entirety of the<br>
>> open source ecosystem would make a lot more sense than each language<br>
>> community creating their own independent solutions that would still<br>
>> need to be stitched together later.<br>
><br>
> so, language/packaging-specific subclasses of e.g<br>
> <a href="http://schema.org/SoftwareApplication" rel="noreferrer" target="_blank">http://schema.org/SoftwareApplication</a> and native linked data would reduce<br>
> the need for post-hoc parsing and batch-processing.<br>
<br>
Anyone sufficiently interested in the large scale open source<br>
dependency management problem to fund work on it is going to want a<br>
language independent solution, rather than a language specific one.<br>
Folks only care about unambiguous software identification systems like<br>
CPE and SWID when managing large infrastructure installations, and any<br>
system of infrastructure that large is going to be old enough and<br>
sprawling enough to include multiple language stacks.<br>
<br>
At the same time, nobody cares about this kind of problem when all<br>
they want to do is publish their hobby project or experimental proof<br>
of concept somewhere that their friends and peers can easily get to<br>
it, which means it doesn't make sense to expect all software<br>
publishers to provide the information themselves, and as a language<br>
ecosystem with a strong focus on inclusive education, we *certainly*<br>
don't want to make it a barrier to engagement with Python's default<br>
publishing toolchain.<br>
<br>
> there are many benefits to being able to JOIN on URIs and version strings<br>
> here.<br>
><br>
> I'll stop now because OT;  the relevant concern here was/is that, if there<br>
> are PyPI-maintainer redirects to other packages, that metadata should<br>
> probably be signed<br>
<br>
Metadata signing support is a different problem, and one we want to<br>
pursue for a range of reasons.<br>
<br>
>  (and might as well be JSONLD, because this is a graph of<br>
> packages and metadata)<br>
<br>
There is no "might as well" here. At the language level, there's a<br>
relevant analogy with Guido's work on gradual typing - talk to someone<br>
for whom a 20 person team is small, and a 10k line project is barely<br>
worth mentioning and their reaction is going to be "of course you want<br>
to support static type analysis", while someone that thinks a 5 person<br>
team is unthinkably large and a 1k line utility is terribly bloated<br>
isn't going to see any value in it whatsoever.<br>
<br>
In the context of packaging metadata, supporting JSON-LD and RDFa is<br>
akin to providing PEP 434 type information for Python APIs - are they<br>
potentially useful? Absolutely. Are there going to be folks that see<br>
the value in them, and invest the time in designing a way to use them<br>
to describe Python packages? Absolutely (and depending on how a few<br>
other things work out, one of them may even eventually be me in a<br>
<a href="http://release-monitoring.org" rel="noreferrer" target="_blank">release-monitoring.org</a> context).<br>
<br>
But it doesn't follow that it then makes sense to make them a<br>
*dependency* of our interoperability specifications, rather than an<br>
optional add-on - we want folks just doing relatively simple things<br>
(like writing web services in Python) to be able to remain blissfully<br>
unaware that there's a world of large scale open source software<br>
supply chain management out there that benefits from having ways of<br>
doing things that are standardised across language ecosystems.<br>
<br>
Regards,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</blockquote></div></div>