JKAN principles

[timwis]

Over the last couple of months, I've been discussing new ideas for JKAN with @BryanQuigley and others. Some of them seem like obvious matches for JKAN (e.g. enabling guests to propose changes via pull request); others seem to run contrary to the ideas behind JKAN (e.g. relying on a free-but-proprietary service); and others sit in between, where it's not obvious whether they're a 'match' for JKAN or not.

So I thought it might be worth proposing a set of principles to help guide decisions for JKAN's direction in the future. That's not to say that the principles can't change; they're more like a checklist to review when considering a significant change, to ensure we've considered them.

Here are the ones I've thought of:

1. Easy to install, setup, and maintain. You shouldn't need to be a web developer to setup or run JKAN.
2. Free and open source. This also means you should be able to run JKAN entirely independently, without relying on particular platforms or hosts.
3. Accessible. JKAN should leverage progressive enhancement, and work well on screen readers, older devices, and browsers without JavaScript.
4. Easy to customise. You should be able to go pretty far with a bit of HTML and CSS knowledge, and well beyond with a bit of Ruby (and perhaps JavaScript) knowledge.
5. Standards-compliant. Make it easy to migrate to or away from JKAN, and to integrate with the open data ecosystem.

What do you think? Are there other principles we should aim to stick to when considering the future direction/features of JKAN? Are any of these too limiting?

[BryanQuigley]

Standards-compliant. would be the hardest in my current understanding, but I agree that is something to strive towards.

Overall Looks good!

[rcheetham]

1-4 seem pretty good. I think standards compliance would need to be carefully defined, and my intuition is that being able to migrate to/from JKAN might be a sixth principle, rather than under standards compliance. For example, standards compliance might refer to other features such as:

• Support data.json standard for browsing/harvesting metadata
• Support syncing records with other catalogs that support data.json
• Support display of GeoJSON files
• Support picklists that include common file format standards (XML, PDF, GTFS, JSON, CSV, SHP, etc.)
• Probably lots of other standards-related functionality

I think the data.json items are probably the most relevant catalog-related feature that might represent commitment to a standard. And then I think a 6th principle: Easy to Migrate Data - support import and export of CSV files - might capture your objective.

[timwis]

Thanks Robert, really good points 👍🏻 I was thinking that sticking to standards like data.json will make migration easier, but I agree that they sound like two separate points.