SEP 60: A stricter metadata vocabulary

Missing terms

As it stands, the only metadata element I am still scratching around for is one that provides an ‘exclusive group’. This had been the purpose of the type element (now retired) but I found the term too vague/loaded.

By ‘exclusive’, I mean a categorical element that can only have a single value. A resource can have multiple tags/subjects and can belong to multiple collections but I like the idea of being able to represent that a resource belongs strongly and exclusively to a given branch/realm, whatever.

I’m also open to discarding this notion. Part of what draws me to hypermedia is precisely the fact that it largely obviates the need for exclusive categorisation, so is such a term actually necessary?

I have found nothing that quite fits in the Dublin Core which, again, perhaps indicates that it is not a worthwhile pursuit. Still, for now I will continue to explore. Brainstorming has so far yielded:

• notebook
• category
• space
• type
• branch
• realm
• journal

Of those, I most like space and category as they generalise well. All the terms could work for document-like resources, but I think only those two are general enough to also accommodate other types of resources: images, videos, papers etc.

As it applies to this site, I basically need an element to encode the wandering, nonsense, pearls, etc.

Miscellaneous notes

type and class will be retired.

Add collection metadata for detecting parent/child etc. A proposal already exists for this, although at that time I had considered using series.

I don’t intend to create a term for ‘newsletters’ at this time. My reasoning is that this is simply the method of delivery of a resource.

20/09/2023 11:18

Explicit terms

abstract

DC:Abstract A summary of the resource.

audience

DC:Audience For whom the resource is intended or useful. 

available

DC:DateAvailable  Date that the resource became or will become available. Would supersede published.

collection

DC:Collection An aggregation of resources.

While I had previously considered introducing the term series, collection generalises better as it does not imply a strict sequence. In the near term this may create minor confusion as I already use the word ‘collection’ within the build pipeline, but this vocabulary can be cleared up.

contributor

DC:Contributor An entity responsible for making contributions to the resource.

creator

DC:Creator An entity responsible for making the resource.

description

DC:Description An account of the resource.

format

DC:Format The file format, physical medium, or dimensions of the resource.

If adopted, would supersede my type element. Should perhaps be coupled with DC:Format:Medium “The material or physical carrier of the resource” where appropriate.

identifier
uid

DC:IdentifierAn unambiguous reference to the resource within a given context.

Currently corresponds with my uid element.

language

DC:Language A language of the resource.

I should decide if I would like for this element to be implicitly assumed to be English where it is not specified, or if I would prefer that it be explicit. Language detection via heuristics at compile time will not be considered.

license

DC:License A legal document giving official permission to do something with the resource.

location

DC:Location A spatial region or named place.

Would usually exist in relation to another term in the vocabulary, eg created > location, available > location, and can possess the following sub-properties:

: lat

The coordinate of the location measured in the lateral direction.

: long

The coordinate of the location measured in the longinal direction.

: elevation

The vertical elevation above mean sea level (AMSL) expressed in metres.

See also DCMI Point Encoding Scheme for further inspiration.

modified

DC:Modified Date on which the resource was changed.

Decide whether this should:

a) not be adopted b) supersede updated c) compliment updated

publisher

DC:Publisher An entity responsible for making the resource available.

This would be used when referencing, for example: a book.

subject

DC:Subject A topic of the resource.

Would supersede tags.

title

DC:Title A name given to the resource.

Derived terms

Derived terms are those which are not specified in the documents themselves, but rather are populated during the build.

backlinks

DC:isReferencedBy A related resource that references, cites, or otherwise points to the described resource.

I should decide if this should come to include external backlinks or if, as with the seperation of references and interlinks, a corresponding element for external inbound links should be created. Such an element could perhaps be called mentions.

interlinks

Here the build inserts a list of internal documents that this document references.

Alternatively, could be rolled into the references hierarchy. For example:

references:
    external:
        in:
        out:
    internal:
        in:
        out:

references

DC:References A related resource that is referenced, cited, or otherwise pointed to by the described resource.

Despite appearances, this does not correspond with my interlinks element. At least for now I intend to reserve interlinks for references between my own documents, as references may be used for external references.