Define a convention for json metadata

[subtleGradient]

Similar to CommonJS/Node.js package.json file standard?

[subtleGradient]

First thought off the cuff...

To add metadata for 42_O01I.CIA in the cia50-a pack...

Add the file "cia50-a/42_O01I.CIA.json"

So there would be one json file for each individual art file.

[subtleGradient]

This json data could be loaded up into a MySQL db or whatever and vice-versa. But keeping a copy of it all as simple text files in github unblocks contribution. Anyone can fork the repo and send a pull request to submit metadata.

[subtleGradient]

Maybe just one json file per pack to start out.

[subtleGradient]

We could generate all the json files with what information we know already. That way people can contribute changes simply by clicking Edit in GitHub.

The generated files would include the sauce data and place holders for all the data we wish we had. As well as a URL to the PNG version of each file in the pack.

[subtleGradient]

YAML may be a better option.
JSON syntax is too strict and doesn't handle merge conflicts well.

[lordscarlet]

I think this is something worth looking at. However, I told @subtleGradient privately: if this is just an attempt to shortcut the route to metadata, I think the master branch is actually really close to being live, and takes care of most of the metadata entry. I don't think we need to do this just in order to have metadata anytime soon.

[ispyhumanfly]

I still find value in exposing at least the option of retrieving metadata in various formats. .json, .yaml and .xml would be nice.

All of this would spawn from our metadata project. For instance, any art pack could be requested directly by URL. If you request a pack and specify .json or .yaml or .xml you'll. receive all meta data associated with this pack in the format requested.

I think it will allow m any third party developers to get access to our data in a encoding type their more familiar with, or, in a format that their module supports directly.

_dan

Sent from my mobile device.

On May 21, 2013, at 11:30 AM, Doug Moore [email protected] wrote:

I think this is something worth looking at. However, I told @subtleGradient privately: if this is just an attempt to shortcut the route to metadata, I think the master branch is actually really close to being live, and takes care of most of the metadata entry. I don't think we need to do this just in order to have metadata anytime soon.

—
Reply to this email directly or view it on GitHub.

[lordscarlet]

Agreed. Like I said, I think it is a valuable endeavor, and linking it to github to allow multiple modes of editing sounds particularly intriguing. I just think @subtleGradient was partially looking for a way to quickly get to metadata. I think we should get to metadata and then start generating these files. From there, we can work on a way to have actual .json/.yaml files that can be edited and synchronized with the database.

[bricas]

@ispyhumanfly well, the api portion satisfies that -- i mean, @cwensley is already using it with PabloDraw.

[ispyhumanfly]

And I guess I'm talking about an "extension" the the API, where we leverage the API, metadata to create seemingly static .json, .xml, .yaml files that act as "containers" for an archive and its related data.

I'm just talking about a new feature build on top of what we've already done.

sixteencolors.net/archive_name.json
sixteencolors.net/archive_name.yaml
sixteencolors.net/archive_name.xml

Are we doing that now?

_dan

On May 21, 2013, at 1:09 PM, Brian Cassidy [email protected] wrote:

@ispyhumanfly well, the api portion satisfies that -- i mean, @cwensley is already using it with PabloDraw.

—
Reply to this email directly or view it on GitHub.