Implement #attributes

[jpstroop]

Will need refinement after the first iteration of plum. Advances pulibrary/plum#1, Closes #6

[tampakis]

Looks good. Just a quick question. Do we care about sorting by creator or title? That would require single-valued fields.

[tpendragon]

@tampakis I suspect that's something to solve at the application layer

[jpstroop]

This is like important for the UI; good point. Probably should add sort_title property sort_creator properties. @terrellt -- what's the best way to do this? Subproperties of the respective dc properties?

[jpstroop]

We could solve creator by sorting by the first one, but it's tougher w/ title because the initial articles would change depending on the language of the record. We easily get this from the record,but it'll be tougher anywhere downstream.

[tpendragon]

@jpstroop We might want to look into returning literals (with language tags) rather than strings at some point, for this use case. If we want #sort_creator/#sort_title (sounds like we want to centralize the logic for deciding which title/creator to sort on because that logic will be standard between applications) then I'd...I don't know, honestly. First pass would be just add a primary_creator and primary_title attribute I think, and let applications filter those keys out if they're not important?

[tpendragon]

If you want to store the metadata in triples, then yeah, a DC sub-property would be the way to go, but you'd have to filter out #primary_creator from #creators I'd think. It gets hairy.

[jpstroop]

I'm less concerned about creators, but I think we should consider sort_title here, because it's so trivial to get from the MARC data, and much harder anywhere else.

[tpendragon]

@jpstroop Sounds good.

[tampakis]

:+1: