-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Advice on ocfl_layout.json contents #351
Comments
#249 is probably relevant to this, if that's helpful |
Discussed this in the Editors meeting. We'll wait for a response from @birkland to see if the linked issues answer his question. |
OK, from the linked issue(s) I derive the following answers:
So at this point, I think I'll just ask around (@tomwrobel ?) to see if anybody has any opinions on Please close this issue if if the editors think this is a good way forward. |
@birkland apologies, I'm just coming across this. I think it's likely that, as you say, some de facto convention will emerge. However, I think it's probably worth guiding the process by example if possible. Would it be possible to a) publish the layout you're using and b) for the implementation notes to link to this layout? It would be a shame if everyone ended up using a pairtree-from-the-identifier approach, but we all ended up with slightly different implementations of it! It's the sort of thing that's very easy to change when first writing code, and very hard to tweak once there are deployed OCFL stores |
@birkland is working on a wiki page here that will allow community members to link to their URIs. This will be closed once that wiki page exists (and is linked to here). |
@birkland I see that I'm supposed to be working with you on this :) Very happy to collaborate - let me know what date/time suits to discuss |
Excellent. I'm away this week with limited internet, but am close to a PR
on this, and have some additional ideas. Will be in touch next week.
…On Mon, Jul 22, 2019, 4:23 AM Tom Wrobel ***@***.***> wrote:
@birkland <https://github.com/birkland> I see that I'm supposed to be
working with you on this :) Very happy to collaborate - let me know what
date/time suits to discuss
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#351?email_source=notifications&email_token=AAD6N6M4HJXAVOUEDOXUWUDQAVU65A5CNFSM4HNYHNN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2PFDFQ#issuecomment-513692054>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAD6N6OAWOB3ZKP2H3TME5LQAVU65ANCNFSM4HNYHNNQ>
.
|
I've been thinking more about this, and I'm beginning to think a github repo for community-contributed RFCs has some nice characteristics over a wiki, particularly as pertains to comment/review (via PRs) before publication. I created a demo github repo with some example RFCs (and a PR for one) in it, along with a README with a little more explanation: an example RFC on github pages: What do folks (@tomwrobel , editors, etc) think about an RFC repo in the OCFL organization> |
Following on from @birkland's suggestion and #365 we have created https://github.com/OCFL/extensions, a PR there would be welcome! Can we close this issue now? |
I'm having some difficulty deciding what to provide for the layout
uri
inocfl_layout.json
. Given the description:... It appears this URI is intended to be used by software clients so that the correct path algorithm is used when creating new objects in an OCFL root. The implementation notes give some examples of such algorithms: flat, pairtree, and truncated n-tuple, but does not mention any recommended URIs to refer to these algorithms in
ocfl_layout.json
. Furthermore, each algorithm has has some sort of choice involved; the value of "N" in truncated n-tuples, or the choice of how to terminate a pairtree, or the choice of whether and how to encode IDs using the "flat" approach. Should these choices be reflected in the URI somehow?If interoperability between clients is a goal of the URI, perhaps the implementation notes should provide a list of URIs or conventions for specifying well-known algorithms.
As an example, it might be reasonable to use
https://tools.ietf.org/html/draft-kunze-pairtree-01
, or maybehttps://confluence.ucop.edu/display/Curation/PairTree
for pairtrees. An implementer might pickhttps://tools.ietf.org/html/draft-kunze-pairtree-01
as it superficially looks more durable. The pairtree spec does does not advocate a specific method to encapsulate an object directory, and notesSo let's say I want to terminate all directories with "obj", so an ID
13030_45xqv_793842495
would result in a directory13/03/0_/45/xq/v_/79/38/42/49/5/obj
. If theuri
inobject_layout.json
is intended to convey this nuance, then maybe I might pick a URL likehttps://tools.ietf.org/html/draft-kunze-pairtree-01?terminal=obj
.or maybe I want a 9-character substring of the original ID, so one might use
https://tools.ietf.org/html/draft-kunze-pairtree-01?substr=9
.But at this point, I feel like I'm just making things up, and don't want to go much farther without advice.
So I suppose my specific questions are:
uri
field ofobject_layout.json
intended to be interoperable between clients?ocfl_layout.json
for well-known path layout algorithms?The text was updated successfully, but these errors were encountered: