Metadata fields: aliases and naming conventions

[Chris Wilper]

I noticed that both Content-Length and content-size are provided (with
the same value) as content metadata. A similar HTTP-style alias
exists for several other built-in metadata fields.

Is one form recommended over the other? Also, is there a
recommendation for naming my own custom metadata fields? (all
lowercase, dashes instead of spaces, starting with "x-", etc?)

Thanks,
Chris

[Bill Branan]

Hi Chris,

When getting metadata, if you're making a REST-style request you should expect to see the usual HTTP headers (Content-Length, Content-Type, etc.) If you're using StoreClient you can either look for those HTTP header values or use the constants defined in ContentStore. It might be time for me to review the need for including the custom fields again, there were reasons for them up front that have mostly gone away at this point. If you look for the HTTP values or use the constants you should get the right values.

When adding/updating custom metadata fields, if you're making REST calls you'll need to include the "x-dura-meta-" prefix on the field name. If you're making the call through StoreClient the prefix will be added for you, so you just need to include the name of the custom field. I would recommend going with metadata names which are in a leading-upper format with dashes rather than spaces (examples: My-Metadata-Field, Another-Metadata-Field). I generally prefer all lowercase letters myself, but the Rackspace interface converts everything to leading-upper format, so if you want a higher likelihood of getting back fields the same way you put them in, you're best bet is to use that formatting.

Bill

--
You received this message because you are subscribed to the Google Groups "DuraCloud Dev" group.
To post to this group, send email to duracl...@googlegroups.com.
To unsubscribe from this group, send email to duracloud-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/duracloud-dev?hl=en.

[Chris Wilper]

Hi Bill,

On Thu, Feb 4, 2010 at 4:57 PM, Bill Branan <bbr...@duraspace.org> wrote:
> Hi Chris,
> When getting metadata, if you're making a REST-style request you should
> expect to see the usual HTTP headers (Content-Length, Content-Type, etc.) If
> you're using StoreClient you can either look for those HTTP header values or
> use the constants defined in ContentStore. It might be time for me to review
> the need for including the custom fields again, there were reasons for them
> up front that have mostly gone away at this point. If you look for the HTTP
> values or use the constants you should get the right values.

Ok, I'm consistently using the constants defined in StoreClient when necessary.

> When adding/updating custom metadata fields, if you're making REST calls
> you'll need to include the "x-dura-meta-" prefix on the field name. If
> you're making the call through StoreClient the prefix will be added for you,
> so you just need to include the name of the custom field.
> I would recommend going with metadata names which are in a leading-upper
> format with dashes
> rather than spaces (examples: My-Metadata-Field, Another-Metadata-Field). I
> generally prefer all lowercase letters myself, but the Rackspace interface
> converts everything to leading-upper format, so if you want a higher
> likelihood of getting back fields the same way you put them in, you're best
> bet is to use that formatting.

Thanks. I was trying to how to figure out how best to allow Akubra to
expose the ability to write arbitrary metadata fields through to
DuraCloud, but I've backed off of that idea somewhat over the last
couple days: It started to look more complicated than I'd originally
thought, and my YAGNI-sense kept reminding me that it's not really
needed for the Fedora-DuraCloud integration anyway. What's really
most useful at this point is to be able to set the mime type on
creation and get the size whenever it's needed, which doesn't require
the use of any custom metadata at all. This thread may be useful to
come back to later, but for now I've got what I need w.r.t. metadata.

- Chris