implement simple metadata format about save-app-ios HOT 16 CLOSED

Now looking into PBCore http://pbcore.org/

from save-app-ios.

Some samples here:
https://github.com/WGBH/PBCore_2.1/blob/master/example_records/simple_description_document.xml
https://github.com/WGBH/PBCore_2.1/blob/master/example_records/pbcore_digital_preservation.xml
https://github.com/WGBH/PBCore_2.1/blob/master/example_records/pbcore_asset_management.xml

Also a nice format for a collection:
https://github.com/WGBH/PBCore_2.1/blob/master/example_records/pbcore_collection.xml

from save-app-ios.

@n8fr8 these fields (author, title, createDate (based on file system on the device), description, license (CC etc), location, tags) look good, but we need to add: Country (researcher is located in), Subject (interviewee), researcher (first, last names/pseudonym) - HRW needs the filename to be formatted like this: 2018-10-29_Country_Subject_ResearcherFirstName_LastName

from save-app-ios.

2018-10-18_USA_kids+love+pumpkins_Nathan_F

from save-app-ios.

This is now being documented here: https://github.com/OpenArchive/openarchive-android/blob/master/docs/OpenArchiveSpaceCapsuleSpec.md

from save-app-ios.

We should (perhaps) mirror the bucket format from Internet Archive... maybe even the metadata XML!

https://archive.org/download/CanadaEh

from save-app-ios.

I wouldn't go so far as to create the thumbnails, too. :-)

Regarding the metadata: I think it's totally fine to use our own (JSON?) format. It's just, that we maybe should keep an eye on what metadata item Internet Archive collects and how it matches to what we have and want.

from save-app-ios.

There is still the question of renaming the files themselves using our new naming convention, or just the they are stored in. In the case of Archive.org, the bucket is named using the title "slug", in the example of "CanadaEh", while the uploaded file(s) retained their original name "canadaehlogo.png".

from save-app-ios.

Ok, I looked at the doc and sent you a pull request for markdown improvements.

Here are my comments/questions:

• LOCATION: For our purposes, Country is the most logical, but any location related data provide
  that can be encoded appropriately (not GPS coordinates), would be useful here.

Why not GPS coordinates? Or only not in the filename? But if we have GPS coordinates in the metadata (which seems very viable to me, e.g. for locations far out in a desert or something), what to put in the filename? Just nothing?

.
+-- Collection-DATE_LOCATION_TILE_SUBMITTER_FLAG/
    +-- Collection-DATE_LOCATION_TILE_SUBMITTER_WARNING.meta.json
    +-- Entry-DATE_LOCATION_TITLE_SUBMITTER_FLAG/
        +-- DATE_LOCATION_TITLE_SUBMITTER_FLAG.jpg
        +-- DATE_LOCATION_TITLE_SUBMITTER_FLAG.jpg.meta.json

Why a subdirectory for every entry? That seems very uneconomic, since there are only ever going to be 2 files in it, which, when name-sorted, will always stick together. Also, this won't help in matching Internet Archive's buckets.

3. BTW - Internet Archive: How to match their metadata format? Our "collection" maps to their "item". And an item has metadata. Most of the metadata we have, maps to theirs, and what not can still be added as custom metadata. (See https://internetarchive.readthedocs.io/en/latest/metadata.html)

Shouldn't we use that instead of our own additional file when uploading to IA?

4. File naming: Wouldn't it be enough to have all the metadata stuff in the collection directory's name? Do you expect that metadata to change that much over the files in a collection?

5. Wouldn't it be possible to have only 1 metadata file per collection? I would argue, that if multiple files in a collection have a different submitter, title, location and date, they should maybe not be in the same collection? That way, we could also show only 1 scene per collection for metadata which is shared accross all the files in the collection, which would automatically nudge the user to create different collections for such disparate content. And the issue of having to repeat the same metadata over and over would be gone.

from save-app-ios.

1. Sure, if GPS coordinates are desired, sure they can be used. I think I meant to say this is more a human readable value, ideally, as opposed to data

2. Each item in a collection is equivalent to a bucket. A folder = bucker

3, 4 5. I will think about this more!

from save-app-ios.

Waiting on you @n8fr8

from save-app-ios.

If a media item is flagged in the client UI, then media file (jpg, mp4, etc) and the associated metadata (json) should be uploaded into a subfolder within the current upload batch folder called "flagged".

from save-app-ios.

Otherwise, what you have implemented now is fine, as long as the .meta.json contains all the fields entered into the app for each item.

I will update the spec document.

from save-app-ios.

I have updated the spec document herE: https://github.com/OpenArchive/openarchive-android/blob/master/docs/OpenArchiveSpaceCapsuleSpec.md

from save-app-ios.

Implemented as specified.

Please note:

The flag is named inside the app as "SIGNIFICANT CONTENT" and is used as a tag. That takes shows up in in the .meta.json file.

That is different than "FLAGGED".

from save-app-ios.

Change subfolder on NextCloud to read "Significant Content"

from save-app-ios.