Documenting DCMIT beyond alphabetical listing

[kcoyle]

I find that an alphabetical listing of terms, as we all seem to do, is fine as a ready reference but does little to explain the logic behind the metadata. I have been trying out various groupings of DC terms as a way to make sense of them. Here's one attempt:

I'm very interested in getting any comments about this. It's definitely a draft and can change in any direction.

[stuartasutton]

Karen, I'd move "audience" to the "Extended Description" block. When first proposed by the DC-Ed group back in 2000(?), its description tied it closely to the education context. However, discussions in the Usage Board resulted in the current, more general definition so it could be applied to a wide range of contexts (e.g., "adult readers", "auto mechanics").

[kcoyle]

Thanks, @stuartasutton. I'll do that in the next version.

[tombaker]

@kcoyle I like your proposal and wonder how it could be implemented - both in terms of semantics (eg, would we have a status property for each of these groupings?) and in terms of documentation.

For documentation, I'm thinking we could perhaps have separate sections for these topics. For ready reference, there could be an alphabetical listing of everything, in addition.

[HughP]

The title of the "academic" block may be more broadly applicable if changed to "scholarly". That said, I'm not sure that any of those elements are just scholarly or academic. The publishing industry in general can use those as do GLAM institutions. I keep needing to remind myself that DC and DC terms need to be thought of in the context of all of the DCMIType vocabulary values, not just the "text" value.

[HughP]

WRT: "Basic Description" I think RDA uses the term "Core".

[kcoyle]

@HughP I like the idea of Core but of course this is Dublin Core so that gets confusing. I also like scholarly and will make that change. It's true that anyone can use any of the terms, but I think that the categories reflect the community that made the case for the terms to be added to DC. Presuming that this diagram would be in a document, there could be some text that explains that this is a view and does not imply any restrictions.

[staplegun]

@kcoyle This Dublin Core Quick Reference Sheet I made in 2008 might be relevant.

I didn't really group them together so much as connect the DC15 with its sub-properties, ranges, encoding schemes, etc. (based on the common thinking at the time).

It was aimed at DC practitioners, so there's a lot of short-hand that would probably be a bit cryptic to the uninitiated (it's kind of #iykyk).

NB: The first column contains the New Zealand Te Reo Māori translations.

[kcoyle]

@staplegun Thanks. That's another interesting way to organize properties and subproperties. I'll see if I can incorporate some of that into my diagram.

[kcoyle]

@staplegun PS. We link to a Maori translation of DC here: http://tereomaoridublincoremetadata.pbworks.com/f/Te_Taura_Whiri_authorised_version_of_Dublin.pdf. It being a pbworks document, I suspect that we should bring over a copy to the DC web site so we don't lose it. The natlib.nz site it points to gives me a 404 and I can't find a copy elsewhere on that site. If you find one, please open an issue here with the link so we can have a stable copy. Thanks!

[HughP]

@kcoyle I noticed just now that Diane set the values up like this:

[kcoyle]

Thanks, @HughP . That's another interesting view. I think we could have more than one way of looking at the terms. I'll take Diane's and see how it expands beyond the core 15.

[niklasl]

@kcoyle I like this a lot.

One way to do this formally (and make it machine readable) would be to define SKOS collections for the various categorizations. I did a quick Turtle representation of your diagram, which you can automatically visualize (using an RDF viewer I'm continuously tinkering with).

This approach lets anyone put together such informative bundles of terms and publish as linked data. (And as skos:Collection is a device supporting "trees", you can build hierarchies of your own liking.)

If we eventually want to "bless" one or more such groupings, we can publish them under the DC namespace and link to them from the dcterms namespace document (e.g. using rdfs:seeAlso).

[kcoyle]

This is beautiful! I love the diagram. Yes I think we can do different viewpoints for different communities, and having a few could encourage others to create their own. Let me think if I can come up with a second view we could play with. In fact, I'm thinking about seeing if DCterms could be visualized as FRBR/WEMI, and then this would fit into @tombaker 's idea of doing openWEMI as SKOS concepts.

[kcoyle]

OK, I couldn't stop myself and I created a first pass at DCterms in WEMI (although it's just "WEM" because I didn't see any item-level terms). I put the ttl file here. I couldn't figure out how to generate the diagram - could you do that for me, please?

[niklasl]

Nice! You can press the little button in the bottom right corner (or press Shift-E) to open an editable area with some rudimentary syntax reporting. Here's the view of that with the edit toggle pressed. There is a dot instead of a comma at line 51 which leads to an error (when the following object is interpreted as an incomplete new subject).

With the edit area opened, you also can also paste different URL:s into the long input field (the editor's "URL bar") and press the little reload button to the right of it.

[kcoyle]

OK, I fixed it and there is now a view of DCMIT here:
https://github.com/dcmi/openwemi/blob/main/examples/dcmiWEMI.pdf

I'm going to post this to the openWEMI group and put it on our agenda for discussion. It's still a very drafty draft. But we can point to it as another view.

[kcoyle]

[HughP]

Interesting analysis. I wonder do you mean to have hasPart under expression? do you mean to have hasFormat under manifestation? These seem to be relationships. Are you saying that certain WEMI entities have have certain relationships? I think I mention this in my paper.