From Library Linked Data
Revision as of 15:21, 20 December 2010 by Ebermes (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Each use case has a number of goals, mentioned in their goals-section. Many goals overlap, but are worded very differently. Sometimes the goals are not clear. That's why it may be a good idea to come to a shared list of goals, and replace the goals description with these standardised goals. Just like we are doing for the Topics and Requirements.

Standardizing the goals will make it much easier to get an overview of all use cases.

Some goals may overlap with Requirements, we need to discuss whether that's a problem or not, and how detailed the goals can be. The easiest way to proceed is to view them simply as handy summaries of the text that is in the Goals section now.

Let's keep the list below as the current accepted list and use the Discussion page to suggest changes.

High-level goals

  • DESCRIBE: describe a resource and/or provide context for a resource.
  • SHARE: share objects description (data) among institutions, not limited to bibliographic data

Make relationships

  • MAP: create equivalence relationships (owl:sameAs, skos:closeMatch) between data items. Can be specialized:
    • MAP(value): create equivalence relationships between instances of value vocabularies
    • MAP(metadata): create equivalence relationships between metadata elements (classes, properties)
  • RELATE (QUALIFIER): represent relationships. This can be used generically as RELATE or with qualifiers to be more specific.
      • existing - to specify representing relationships between the entities that already existed in the data
      • new - to specify new relationships between entities (e.g. Use Case Mapping Scholarly Debate) either using machine processing (inferences, alignments, etc.) or manually (tagging, cataloguing)
      • aggregations - to specify aggregations

Use relationships

  • DISCOVER/SUGGEST: use existing links to discover/suggest other items.
  • SEARCH/BROWSE: provide search and browse facilities over the RDF data
  • FEDERATE: discovery over many sources (federated or union discovery), across different domains, without creating a single data store.
  • AGGREGATE: create a single data store from the aggregation of many sources
  • MANAGE: use (heterogeneous, including non-bibliographic) data to carry on specific tasks for professional purposes, library management purposes.

Represent original data as RDF

  • REUSE-SCHEMAS: reuse existing RDF schemas {FOAF, ORE, ...} that represent metadata element sets in publishing the data as RDF
  • REUSE-VALUE-VOCABS: reuse existing vocabularies already published as LOD {LCSH, GTAA, ...} in publishing the data as RDF, i.e. replacing internal identifiers with URIs from these vocabularies.
  • URIS: provide URIs for entities in the UC [INSERT ENTITY NAMES]

Publishing & Services

  • API: provide an API to access / change the data.
  • PUBLISH: publish the data in particular formats: {RDF, RDFa, HTML, ...}
  • NAME WITH URI: provide URIs for entities in the UC [INSERT ENTITY NAMES] (Emma wonders whether providing a URI is really a "goal" instead of a "requirement")