Mints an object whether there's a URI or not, partly to support SPARQL endpoints, makes labels available/searchable through SPARQL. Other advantage is ability to expand upon term over time, add more links to other terms, etc.

Eben put question out to Code4Lib list to ask about using combination of literals and objects and the one person to respond recommended against it

Will assume that similar strings are the same

Allows for updating labels for every instance in records

Adds other proprties pointing to subelement mappings, ex. dcterms:spatial for geographic subheading pointing to respective subheading in another authority

Question about spatial object properties: if you have an exactMatch to an object with coordinates, is it overkill to include your own coordinates? (ex. DCE:coverage "east=42...)

For local complex terms or complex headings where only subheadings have corresponding URIs, proposed to include rdfs:label for each subheading (but not for complex headings with URI matches?)

Question: what will the workflow be for creating new subject entries? A: could be autocomplete with existing terms or create a new subject object by entering term (and trying to match?) or URI and pulling labels from matched URI.

Things not mapped: temporal (edm:timeSpan)

NYPL looking at option to use combo of edm:timeSpan, PeriodO (http://perio.do/ ), other vocabs with dcterms:temporal property

Hierarchical geographic: a bad idea to try to represent entire hierarchy? You really just need most specific point. How to represent specific addresses? Spatial object would have to have some way to represent full address in addition to coordinates

For next meeting, flesh out examples for these geographic and temporal elements