Make package.json be JSON-LD

[cmungall]

On the eat-your-own-dogfoot principle, shouldn't
https://github.com/digitalbazaar/jsonld.js/blob/master/package.json

Have a context tag added?

Feel free to close this item without resolution as out of scope. But I thought it would make a nice example. And I need to generate some rdf from package.jsons for another project it would be good to have a standard context here.

[dlongley]

An interesting idea, but we don't have enough time to come up with a standard context for package.json yet. Seems like some collaboration with npm would be good there as well.

[bollwyvl]

This is an interesting problem, indeed. Kind of takes me back to my first work with node.js: package.json validation work on cndjs.

Which package.json?
Since then, npm has been "blessed," so that probably would make the most sense rather than trying to support commonjs, jquery and all the other "specs" out there at the time.

Which ontology?
In terms of the ontology with the most mass out there in this space, I imagine it would be DOAP... python's PyPi uses it, for example.

The up-and-comer in this space is SPDX, which DOAP now uses for licenses, and uses doap:Project in turn.

What about dependencies?
The dependencies and devDependencies entries are some of the richest pieces of information in a package.json, but seem somewhat opaque to manipulation by contexts/framing. Further, neither of the above project ontologies really tackle this issue.

Taking some liberties here, doap:dependency is not really a thing, and even if it was, wouldn't be about versions! These problems aside, is there a JSON-LD way to turn:

{
  "name": "foo",
  "version": "0.0.1",
  "dependencies": {
    "jsonld": "0.1.24"
  }
}

Into something with good URIs? Maybe something like this?

[{
  "@id": "https://npmjs.org/package/foo#0.0.1",
  "http://usefulinc.com/ns/doap#release": "https://npmjs.org/package/foo#0.0.1"
},
{
  "@id": "https://npmjs.org/package/foo#0.0.1",
  "http://usefulinc.com/ns/doap#revision": "0.0.1",
  "@type": [{"@id": "http://usefulinc.com/ns/doap#Version"}],
  "http://usefulinc.com/ns/doap#dependency": "https://npmjs.org/package/jsonld#0.1.24"
}]

[elf-pavlik]

<3 this idea! just invited other folks participating in W3C RDF JavaScript Libraries CG to tackle it together -- http://lists.w3.org/Archives/Public/public-rdfjs/2014Jan/0000.html

[elf-pavlik]

we started discussing on a thread linked above how to describe people
https://npmjs.org/doc/json.html#people-fields-author-contributors

{
  "@context": {
    "url": "@id"
  }
}

possibly trying not to make dependencies a road block and start with more straight forward parts!

[elf-pavlik]

@EDumbill http://npmjs.org has as of today

Total Packages: 53 284

we could help with making them proper DOAP by crafting JSON-LD context and one page with few guidelines what to keep in mind while writing package.json

i could also talk with npm community to make it an option in $ npm init

[ewilderj]

npm init option is smart
also, could you bootstrap the process by making an app that either
generated template package.jsons for all modules right now, or did it as a
service for them on demand?

On Fri, Jan 3, 2014 at 8:29 AM, ☮ elf Pavlik ☮ notifications@github.comwrote:

@EDumbill https://github.com/edumbill http://npmjs.org has as of today

Total Packages: 53 284

we could help with making them proper DOAP by crafting JSON-LD context and
one page with few guidelines what to keep in mind while writing package.json

i could also talk with npm community to make it an option in $ npm init

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-31533715
.

+1 (415) 692 1767 • http://about.me/edd • http://google.com/+EddDumbill

[elf-pavlik]

i've just started writing down DOAP based context at: https://github.com/edumbill/doap/wiki/JSON-LD-@context-for-package.json

[bollwyvl]

@EDumbill i like the on-demand service idea... it's too bad there isn't a blessed avenue for this kind of automation, as discussed here.

@elf-pavlik starting is always good! I added homepage, and fixed a small typo.

I've been playing with the playground (and the experimental one with syntax highlighting), and looking at some example package.json documents:

• express
• d3

issues encountered so far:

• I didn't know about this interpretation of url from the npm doc about homepage:

  This is not the same as "url". If you put a "url" field, then the registry will think it's a redirection to your package that has been published somewhere else, and spit at you.

  Literally. Spit. I'm so not kidding.

  Learn something new every day! However, I submit that name is actually a much stronger URI, when combined with "@base": "https://npmjs.org/package"

• people get complicated, and not only for the object vs. string representation (express uses both!). For some reason, I thought this would be valid:

    "name": "doap:name",
    "author": {
      "@id": "doap:maintainer",
      "@type": "foaf:Person",

      "name": "foaf:name",
      "url": {
        "@id": "foaf:homepage",
        "@type": "@id"
      }
    },

well, it parses, but does nothing useful with the content it finds. still tinkering...

[bollwyvl]

Poking about a bit more in the npm source, and on some of the things that are exposed on registry.npmjs.org, I think what may make sense initially is to describe with a JSON-LD context the output of the registry, which has already been cleaned up, rather than try to work with/against the authors of individual package.json files.
Because of registry preprocessing and CouchDB backing, magical things start happening.

Continuing with my examples from above, here are express and d3 on the registry:

• express
• d3

Here are some assertions (based on maybe wrong assumptions):

_id === @id, name === doap:name

To my knowledge, JSON-LD can't map the same key to two triples, but CouchDB gives us _ids in a few key places. So now, the project actually is the main node of the document (instead of a cross between a particular version and the project):

{
  "_id": "express",
  "name": "express",
...
}

Can be understood with:

{"@context": {
  "doap": "http://usefulinc.com/ns/doap#",
  "@base": "http://registry.npmjs.org/"
  "_id": "@id",
  "name": "doap:name"
}}

versions === doap:revision

While versions are captured explicitly:

{
  ...
  "versions": {
    "3.4.8": {
      "_id": "express@3.4.8",
      "name": "express",
      "version": "3.4.8"
    },
    ...
  },
  ...
}

and could be understood with:

{"@context": {
  ...
  "versions": {
     "@id": "doap:release",
     "@container": "@index"
  }
}}

This now gives us strong identities for versions, a la http://registry.npmjs.org/express@0.14.0, which is part-way to describing the dependencies relationship (were that to be modeled in DOAP, see above).

author === maintainers, contributors === developers

This is much more consistent, as only the object form is present.

{"maintainers": [
  {
    "name": "tjholowaychuk",
    "email": "tj@vision-media.ca"
  }
]}

can be understood with:

{"@context": {
  ...,
  "foaf": "http://xmlns.com/foaf/0.1/"
  "author": "doap:maintainer",
  "contributors": "doap:developer",
  "email": "foaf:mbox"
}}

Unfortunately, it drops the url property and I don't see how JSON-LD could add the canonical mbox: prefix, so it can't be an URI... which is kind of unfortunate... but then, personal identity is one of those long-term problems.

more on dependencies

The next piece of the dependencies puzzle requires turning the key-value pairs into URIs, which I don't see a way to achieve directly... the above @index trick with versions works because the information is duplicated inside the object. With dependencies, the information is denser. Some (ludicrous) solutions:

• Treat each line of dependency as a subProperty of doap:dependency for each each package?
• Use macros?
• Introduce a new type of @container?

The final piece is a "dependency set"... such as express@3.4.8 requiring debug at version >= 0.7.3 < 1. Presumably, this could be expanded into an inferred set of doap:revisions of debug, which, humorously, would require semantic versioning inside a semantic datastore. Sounds like SWRL or some such embedded rule system, which is pretty far outside of scope.

Still looking at things...

[dlongley]

See: https://github.com/standard-analytics/ldpm and https://standardanalytics.io/package

[kevinSuttle]

See also:
npm/npm#4482 (comment)
npm/npm#10859
npm/npm#10832
https://schema.org/SoftwareApplication
And regarding package icons schemaorg/schemaorg#939

[elf-pavlik]

http://linkedsoftwaredependencies.org/bundles/npm/jsonld

https://linkedsoftwaredependencies.org/

Read why semantic software configurations improve experiment reproducibility
Access 475,000+ npm JavaScript libraries as 150,000,000+ RDF triples using TPF, HDT or Turtle
Perform queries over software modules
Instantiate software with Components.js, a semantic dependency injection framework
Find our source code on GitHub

It looks like @rubensworks works on it

[rubensworks]

Indeed, we ( @joachimvh, @RubenVerborgh and myself) are working on this.

Note that our mapped JSON-LD does not exactly correspond to the structure of the original package.json, because some parts are not directly convertable. @joachimvh did most of the work on this part, so he can provide further details on this.