SRFI-metadata-syncing SRFI?
noosphere@xxxxxx
(08 Nov 2020 21:50 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
Vladimir Nikishkin
(09 Nov 2020 01:00 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
Lassi Kortela
(09 Nov 2020 09:41 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
noosphere@xxxxxx
(09 Nov 2020 16:15 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
Lassi Kortela
(09 Nov 2020 16:36 UTC)
|
||
(missing)
|
||
Re: SRFI-metadata-syncing SRFI?
noosphere@xxxxxx
(09 Nov 2020 20:35 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
Lassi Kortela
(09 Nov 2020 20:57 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
Lassi Kortela
(09 Nov 2020 21:05 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
noosphere@xxxxxx
(09 Nov 2020 23:41 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
Lassi Kortela
(10 Nov 2020 07:53 UTC)
|
||
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 23:45 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
noosphere@xxxxxx
(09 Nov 2020 20:50 UTC)
|
||
Re: SRFI-metadata-syncing SRFI?
Lassi Kortela
(09 Nov 2020 21:12 UTC)
|
||
The funnel pattern
Lassi Kortela
(09 Nov 2020 21:30 UTC)
|
On Mon 09 Nov 2020 10:57:15 PM +02, Lassi Kortela wrote: > > A further benefit of storing in the Scheme implementation's repo is that > future source releases (tar files) will automatically contain info that > is up to date for that release. So even if we lose the version control > history, anyone having the tarball for a release can retrieve the > metadata. We've found and resurrected quite a few old Scheme > implementations for the Docker containers, and empirically, the tarballs > are by far the most resilient format for long-term archival. > > If the standardized metadata files take off, a future aggregator could > read them and then merge in the file containing missing information from > old implementations. Does this sound reasonable? This sounds reasonable to me. I was just against scraping unstructured data as a long-term solution. As long as the data that's scraped is structured and designed to contain desirable metadata, then I have no objections to storing it in the implementation's tar file. And, like you say, it is a good way to make sure the metadata is archived in an authoritative location for future use. --Sergey