An outsider's feedback on public draft 0.5

[Martin Haye]

Hello,

I'm new to the group, having just learned of ResourceSync at LibDevConX in California. I'm really excited about ResourceSync, and since you asked for feedback here it is. Please forgive me if I repeat topics that have been discussed before I joined, and I desperately hope I won't step on any toes.

I read through the 0.5 spec and the following came to mind. Feel free to take or leave any of my suggestions. Also, any topic that needs fuller discussion could be broken into a separate thread on this list.

- First, I love the whole concept. I can start with SiteMaps which I'm already generating, and make them that much more useful by incrementally adding ResourceSync.

- It's a great idea to expose the mod time I was left unclear (and maybe I just missed it) whether the mod time of a "parent" file like the Capability List should always have a mod time *after* the lists it points to (in other words, basically the max of all their mod times), or if its mod time is its own.

- It might be useful to clarify that Change Lists should be in *forward* chronological order. My initial thought was reverse-chrono but I think that's not what was intended.

- The order of presentation in the introductory parts is wonderful. Start from things I already know, like Site Maps, and gradually build to larger concepts. I read a fair number of specs, and the approach taken here is excellent.

- My one quibble order-wise is that the detailed specification of the Capability List, which is one of the very few really required parts, is way at the end. I could easily imagine a reader's eyes glazing over before they reach that very important section. Maybe the Capability List could lead the sections after the introductory material is done?

- For my repo escholarship.org which has ~50,000 objects, I think I'd like to publish two Resource Dumps: one that just has metadata and will thus be small, and then a big one containing all the data. I guess I should advertise the capability of two resource dumps, but the spec left me very unclear how I should make it clear to an automated harvester which dump is which. Even better, I'd like to tell them what kind of metadata to expect (Dublin Core XML in my case). Any clarification on the proper way to do this (or at least an adequate way) could be a very helpful addition to the spec.

- In the part of the spec talking about Resource Dumps, it would assist comprehensionl to include a simple textual diagram of the insides of an example zip file, so a reader can see what files are present in which directories. It would make the discussion of paths easier to grasp.

- I love that you're keeping things simple and keeping the spec small. With regard to adding push capabilities, I might suggest isolating that to a separate spec to preserve the tight focus and reader-accessibility.

That's all for now. Fantastic ideas, a great job on the spec, and I very much look forward to commenting on (and helping with) future drafts!

Best regards,

Martin Haye
a repository programmer
at the California Digital Library

[Richard Jones]

Hi Martin,

> - For my repo escholarship.org which has ~50,000 objects, I think I'd like
> to publish two Resource Dumps: one that just has metadata and will thus be
> small, and then a big one containing all the data. I guess I should
> advertise the capability of two resource dumps, but the spec left me very
> unclear how I should make it clear to an automated harvester which dump is
> which. Even better, I'd like to tell them what kind of metadata to expect
> (Dublin Core XML in my case). Any clarification on the proper way to do this
> (or at least an adequate way) could be a very helpful addition to the spec.

This is interesting to me too at the moment, in a slightly different
context. We're attempting to build something using ResourceSync which
meets the OAI-PMH use case of providing a feed of metadata changes.
In order to do this in a way that is compliant with the ResourceSync
approach, and attempting to avoid just replicating OAI-PMH
functionality, we've decided to annotate each url in a resource list
with an rs:ln element with rel="describedBy" and the href equal to the
namespace of the metadata format. So:

<url>
<loc>http://example.com/metadata-resource</loc>
<lastmod>2013-01-02T17:00:00Z</lastmod>
<rs:ln rel=”describes” href=”http://example.com/bitstream1”/>
<rs:ln rel=”describedBy” href=”http://purl.org/dc/terms/”/>
<rs:ln rel=”collection” href=”http://example.com/collection1”/>
</url>

You could probably re-use the same approach within the Capability List
to point to a resource dump which is describedBy the metadata format.

I'd be interested in hearing your thoughts on it; there's certainly an
element of special knowledge required at the client end to understand
this, rather than it being baked into the standard, but I think that's
a deliberate decision.

Cheers,

Richard

>
> - In the part of the spec talking about Resource Dumps, it would assist
> comprehensionl to include a simple textual diagram of the insides of an
> example zip file, so a reader can see what files are present in which
> directories. It would make the discussion of paths easier to grasp.
>
> - I love that you're keeping things simple and keeping the spec small. With
> regard to adding push capabilities, I might suggest isolating that to a
> separate spec to preserve the tight focus and reader-accessibility.
>
> That's all for now. Fantastic ideas, a great job on the spec, and I very
> much look forward to commenting on (and helping with) future drafts!
>
> Best regards,
>
> Martin Haye
> a repository programmer
> at the California Digital Library
>

> --
> You received this message because you are subscribed to the Google Groups
> "ResourceSync" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to resourcesync...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

[Herbert Van de Sompel]

Dear Martin

Thank you so much for your mail. It is very encouraging for us and we will definitely take your observations/suggestions into account! Please spread the word. We would like to hear from more potential adopters.

Herbert

Sent from my iPad

--