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