Comparison and analysis of W3C UCR documents

From Dataset Exchange Working Group

Analysis of W3C UCR documents with regard to resource organisation

POWDER: Use Cases and Requirements

  • Related UCs thematically grouped according to a single common function/task --> similar to tag filter (multidimensional)
  • Link list to reqs motivated by UC
  • Similar for requirements, but with different groupings, no further links

CSV on the Web: Use Cases and Requirements

  • Plain listing of UCs, each has own ID as part of title
  • UCs link to reqs in flow of motivating scenario --> UC text immediately motivates reqs, relation becomes obvious
  • Requirements grouped primarily by acceptance level (accepted, partially accepted, deferred), explanation given by inline notes
  • There are few high-level reqs (toc references) internally split up into detailed ones (no toc reference)
  • Reqs link back to motovating UCs

Data on the Web Best Practices Use Cases & Requirements

  • No UCs grouping, link list to reqs
  • Special requirement naming ("R-" prefix) --> easies the identification/search
  • Req. organisation: Thematic group > Meta-requirement > Sub-requirements
  • Req. content is very brief and focused, no notes, UC links only --> easies readability

Linked Data Platform Use Cases and Requirements

  • Document starts with informative user stories
  • "Statements about system requirements written from a user or application perspective"
  • Provide the overall rationale and describe the usage context
  • UCs are more fine grained and focused on system’s behavior (i.e. particular application of the standard in question)
  • Supports the requirement definition by specification of a primary and alternative scenarios
  • DXWG UCs mix both perspectives
  • Reqs grouped as functional vs. non-functional
  • Req. names are cryptic IDs, no labels
  • Reqs not structured at all, one-liners with a link to a single motivating UC

Use Cases and Requirements for the Data Catalog Vocabulary

  • Original UCR document by DERI
  • UCs less formal, no links to reqs, unique ID within title
  • No organisation for reqs
  • Reqs are mostly one-liners with a link to one or multiple motivating UCs
  • Reqs content is higher-level, rather corresponds to our "meta-requirements"