<br><br>On Monday, August 21, 2017, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21 August 2017 at 19:38, Paul Moore <<a href="javascript:;" onclick="_e(event, 'cvml', 'p.f.moore@gmail.com')">p.f.moore@gmail.com</a>> wrote:<br>
> On 21 August 2017 at 09:54, Nick Coghlan <<a href="javascript:;" onclick="_e(event, 'cvml', 'ncoghlan@gmail.com')">ncoghlan@gmail.com</a>> wrote:<br>
>> While I'm still generally negative on the idea of native reliance on<br>
>> JSON-LD, I'll note one thing that has changed since I last looked at<br>
>> it: I now see some potential concrete practical benefits to adopting<br>
>> it, rather than purely theoretical ones. In particular,<br>
>> <a href="https://github.com/scienceai/jsonld-vis" target="_blank">https://github.com/scienceai/<wbr>jsonld-vis</a> now exists, and there wasn't<br>
>> anything like that around at the time of previous discussions.<br>
><br>
> Personally, I fairly often write adhoc scripts that use the JSON API,<br>
> and as it stands it's very convenient for that. From what I can see of<br>
> JSON-LD (which basically equates to "it adds some extra metadata keys<br>
> that don't change the data content but do change the list of keys and<br>
> maybe the nesting levels") it would be somewhat inconvenient for my<br>
> scripts, and add no extra capability that I would ever use.<br>
<br>
Right, and this is still my main concern with the idea as well: I'd<br>
never be OK with a JSON-LD-only API, because it adds too much<br>
irrelevant cognitive overhead for the vast majority of Python<br>
packaging specific use cases. (I would see it as being akin to Python<br>
itself deciding to require type annotations, rather than merely<br>
allowing them).<br>
<br>
However, where I'm starting to see a potential niche for it is as an<br>
opt-in capability, whereby we explicitly define how our metadata can<br>
be translated *to* JSON-LD, for folks that want to apply general<br>
purpose tools that know how to manipulate arbitrary JSON-LD data (like<br>
the graph visualiser I linked earlier).<br>
<br>
That way, everybody wins - folks that have never heard of <a href="http://schema.org" target="_blank">schema.org</a><br>
or linked data in general won't need to learn any concepts that are<br>
completely irrelevant to them, while folks that are aware of those<br>
things and the related tools will be free to use them without first<br>
having to figure out their own mapping from the Python specific<br>
metadata formats to a JSON-LD compatible format.<br>
<br>
That approach then doesn't even need to wait for PEP 426: it could be<br>
done using the wheel METADATA file as a basis instead.<br>
<br>
It will probably still be up to Wes to actually define that<br>
transformation though - I don't think anybody else is anywhere near<br>
keen enough to make use of the available JSON-LD tooling to spend any<br>
time working on enabling it :)</blockquote><div><br></div><div><div>So,</div><div><br></div><div>## Justify JSONLD</div><div>- This is a graph. If we use an existing spec for graphs as JSON (ie JSONLD), we win:</div><div>  - all of the tools that already exist for working with said graphs in that format</div><div>  - easy indexability (as RDF quads)</div><div>  - compatibility with compatible specs like ld-signatures</div><div><br></div><div>## Implement JSONLD</div><div>- [ ] decide which URI(s) a project on {pypi,} is identified by</div><div>   - some projects should not have an implicit <a href="http://pypi.org">pypi.org</a> URI prefix</div><div>- [ ] write a new JSONLD view for pypi and warehouse</div><div>- [ ] write a JSONLD metadata spec for eggs and wheels</div><div><br></div><div>## Support metadata retrieval without exec'ing setup.py</div><div><br></div><div>- develop a declarative format for expressing {sys.platform[...],}-dependent dependency edges</div><div><br></div><div><br></div><div>Signed,</div><div>Wes T.</div></div><div><br></div><div>P.P.S. This is just a hard week for me,</div>