Re: Problems and Opportunities at

Good news - The W3C (almost) has a Recommendation for CSV.  Finally
standardizing the format.

On Tue, Dec 1, 2015 at 2:15 PM, Stian Soiland-Reyes <> wrote:

> Thank you,
> I agree on all points :))
> Some simple file format should be sufficient for most cases, then generate
> to $currentMainstream technology, or translate to $otherFormat.
> What I like about CSV - as awkwardly unspecified as it is, is that it is
> easy for non-techies to understand, so we could keep the current Github
> pull request model for a while.
> YAML could be another candidate, but then there's indentation to worry
> about. JSON and XML are hard to hand-edit.
> Content-negotiation is one "fancy" thing that has been mentioned on w3id
> list ( doesn't do this), but if we were to agree to support it,
> that should be sufficient to add later as an additional mediaType column or
> similar.
> OK, so let's get some quick code repository up and running that can do
> csv->htaccess or similar! Python or Ruby? :) (deliberately not proposing
> Node.js here..)
> Former OCLS/purl guys, what is the current schema, or in what form could
> we get the data? I can kind of deduce most of it from the UI and seen the
> documentation for batch updates (which I never got to work myself).
> On 30 Nov 2015 17:04, "Norman Gray" <> wrote:
>> Greetings.
>> [apologies for the delay here: it was Stian's recent message that
>> reminded me I wanted to reply to his earlier one]
>> On 23 Nov 2015, at 11:45, Stian Soiland-Reyes wrote:
>> What I see a danger with proposing some new $shinyServerSoftware is that
>>> we can
>>> easily bind ourself into the same trap as - becoming high
>>> maintenance
>>> sysadmin-wise, and potentially relying on abandoned technology.
>>> Apache HTTP server also scales very well, and you can't say it's
>>> proprietary
>>> or at immediate risk of being abandoned. :)
>> I think we should remember that the _short term_ here is one or two
>> decades, and that in this context the 'long term' implies preservation
>> 'beyond one technology generation', and thus axiomatically dealing with
>> Apache httpd's successor, rather than merely what mod_rewrite's manual
>> looks like in 2025.
>> I don't think we have to worry about the transition to URLs' successor,
>> since PURL++ will surely be swept up in whatever web-wide transition path
>> that requires.
>> Thus I believe that at this stage we should not be thinking of
>> $shinyServerSoftware at all, but of what the preservation data format is
>> (.csv files?) and how the schema is documented (.txt files).  Turning that
>> into an actual service (doubtless using httpd and .htaccess files to begin
>> with) is Just A Matter Of Code.
>> So...
>> What I like is the ideas that have been proposed to have a kind of "build"
>>> stage with more managable CSV files or something, that then "compile"
>>> into .htaccess or XML or whatever you fancy using a
>>> straight-forward Python/Ruby/nodejs script.
>>> [...]
>>> This would also mean also that libraries and researchers could use &
>>> archive
>>> the w3id "database" without having to parse .htaccess or do thousands of
>>> HTTP
>>> request.  (We might want to clarify the license on that database!)
>> ...I think I'm agreeing with Stian here, but possibly being more emphatic
>> about it.
>> So, a concrete question: what is the format of the data?  I
>> imagine a rather simple db schema.  For the reasons above, I think that we
>> should not regard a tree of .htaccess files as anything other than than
>> disposable, or intermediate, implementation technology.
>> but we would need to migrate the existing <>
>>>>> PURLs forward, I think.
>>>> In the same spirit, is that _really_ the case?
>>> Not migrating would undermine the whole reason for having -
>>> how would
>>> anyone trust to use us if suddenly we wipe the existing
>>> identifiers?
>> First: I doubt it would be necessary in fact to abandon anything at
>>  That said, I think it would be good to retain the option in
>> principle.  If there's a robust model for purl++ which happens to undermine
>> one or two of the more creative current .htaccess redirections, then the
>> long-term preservability (ie, 2--10 decades) is arguably more important
>> than preserving a redirection that's been in existence for only a fraction
>> of that.  This is an argument about priorities, not a proposal for deletion.
>> That would count as a decent rationale for 'deaccessioning' those w3ids
>> (and deaccessioning is something archivists are forced to do from time to
>> time).
>> The current collection should be quite managable to convert manually in a
>>> couple of days - so I don't see this as a big issue.
>> Ditto.
>> Being able to support pretty much of all of the existing
>>> redirects is
>>> however much more important.  They should all be rewritable to .htaccess
>> ...or to something which is mechanically implementable as .htaccess.
>> All the best,
>> Norman
>> --
>> Norman Gray  :
>> SUPA School of Physics and Astronomy, University of Glasgow, UK

Shane McCarron
Managing Director, Applied Testing and Technology, Inc.

Received on Tuesday, 1 December 2015 22:22:02 UTC