use-cases: new case study based on Versioning tutorial dataset

[jorgeorpinel]

In https://dvc.org/doc/tutorials/versioning

• Moved to use-cases: create dataset for new use case dataset-registry#2: The datasets (actually 2 parts of the same dataset) in that tutorial are currently 2 ZIP files, data.zip and new-labels.zip. We should extract the first dataset into a directory as a first version. Then we'll extract the 2nd one on top and update the dataset version.
  UPDATE: Done. See iterative/dataset-registry /use-cases

Then we'll create a use case based on this dataset, following the comments below (from Ivan):

for the “Datasets registry”/“Data registry” (high level usage scenario) we can use cats-and-dogs as an example - before S3 within some random bucket, and evolution as a new zip with new images

replace ZIP archive with actual directory with images with two revisions of those so that you can dvc import it, then use dvc update to get the latest version (2x images)

and in the use case just mention - that see - this how ugly it looks like when datasets come and evolve out of DVC control, the better way can be to organize datasets registry - which can enable reusability, tracking of changes in Git-like fashion, versioning, etc

in this case ZIP is not actually needed + it means you are duplicating 1000K images

[jorgeorpinel]

From @shcheklein:

Maybe as part of this case study we can show an evolution briefly - how it was wget first (ad-hoc path in S3, not tracking, no guarantees that data stays the same, etc), then this dvc get to introduce tracking (see who changed what) + now it’s guaranteed that data is not changed. And now dvc import + directories - to properly use directories (easier to manage, potential benefits storage-wise), to keep the connection.

(In the context of possibly going back to using wget directly from S3 as opposed to dvc get ZIP data files in the versioning tutorial [and get started].)