From Last Meeting
- What is the scope of data that the change management documentation covers? (e.g. authority data, bioliographic data, other)
- What is a good name for topics in this area in general? (I am looking for a name that can be used for name-spacing technical documents like URIs in the context document.)
- Review IIIF format of activity streams documentation (https://iiif.io/api/discovery/1.0/)
- Take a look at example context document (https://iiif.io/api/discovery/1/context.json)
- Review updated activity streams document
- Activity Streams - Extensions for Authoritative Data Change Management (min extensions + instruments)
Return structured information where the data may be lean (e.g. agrovoc term) or complex (e.g. wikidata entry).
In MARC less agreed upon structure which creates more variety and less clear way to express change. In process to define structure for exchange of data, but this is new and not fully defined.
First steps toward semantic search engine. Right now very focused. But as expands, the data will be more complex.
ShareVDE CKB data is viewed as entity data. The data is a description about an entity.
Many of the authorities we've discussed come from organizations that curate their data (e.g. LOC, Getty, Agrovoc, etc.) providing a certain standard.
What about VIAF and ISNI, where much of the data is <same_as> to other URIs in other sites. Provides an aggregation of authority data from many sources.
Wikidata represents entities and relationships.
OCLC Identities represents as an entity project, but still works as a traditional authority. Ex. if find a person, there will be same-as
Agree that moving toward a URI as identifier with a consistent label for presentation to users. The label then becomes flexible in terms of language.
Authority Data (e.g. LOC Subjects, MeSH,
- focus is to define and authorize headings and provide this to institutions that need headings
- perhaps heading is not exactly the right terminology; MeSH is a hierarchy of terms which leads to a label; URI is the meaningful identifier; other data becomes properties; similar for places where the label may be ambiguous and the URI is more precise giving an authoritative identify or reference; the URI is an unambiguous key
Things Data (e.g. Person, Place, Organizations)
- descriptive data about a real world thing, e.g. object or place
- typically have been placed in authority data (e.g. LOC Names, Geonames)
- additional properties beyond label are primarily present to support disambiguation
Controlled Vocabularies (e.g. Agrovoc, Homosaurus, OLAC)
Relational Data (e.g. ISNI, VIAF)
- make connections between using <same-as>
- seen as authority data
Bibliographic Data (e.g. LOC Works and Instances)
- works and instances
Descriptive Data (e.g. ShareVDE CKB)
Entity Data (e.g. WikiData)
- URI + Label
- Interlinked subjects
- Disambiguation properties
- Notification to a single institution when a requested entity that was missing becomes available. This will likely be outside the main change management stream.
- Value of diagraming to express changes as a means of conveying information around where data is being produced, where it goes, etc.
- Partial splits and partial merges.