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:

1. not be adopted
2. supersede updated
3. 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.