| | 1 | Current Situation |
| | 2 | ----------------- |
| | 3 | |
| | 4 | A resource belongs to a single package. A resource can only hold very limited pieces of information i.e a url, hash, a description and its format/type. It also has state i.e whether it is active and not active. They are versioned but not dated. |
| | 5 | |
| | 6 | The user is given an option to reorder the resources against a package, this order has no relevance apart from how the information is displayed. |
| | 7 | |
| | 8 | |
| | 9 | Use Cases |
| | 10 | --------- |
| | 11 | |
| | 12 | * Data should be able to be grouped by various different factors (type, date). |
| | 13 | |
| | 14 | * There needs to be a mechanism to timeline information the user puts in, so that search results only display the latest package. This needs to be done in a way that the older data is still easily accessible. This should be done with the minimum of user effort. |
| | 15 | |
| | 16 | * The ordering of the data should be presented without the need for user input. |
| | 17 | |
| | 18 | * There needs to more information stored against the data, beyond just its format and a description. |
| | 19 | |
| | 20 | * Users should be able to refashion the data and post a whole new set of this refashioned data. |
| | 21 | |
| | 22 | * Groups of data should be able to be synced across packages/instances. |
| | 23 | |
| | 24 | * When new versions of the data arrive it should be easy to copy an old one and change versions as required. |
| | 25 | |
| | 26 | * A user may want to upload a resource separately from the package and decide later on where its the best place for it is. |