RdfAffordances

From W3C Wiki

Introduction

Definitions : An affordance is a quality of an object, or an environment, that allows an individual to perform an action. An RDF Affordance is a resource description which gives a client all the information it needs to perform an action (provisional definition).

For example - around linked data we talk about the Web's follow-your-nose protocol. There are several facets to this protocol.

For HTML :

  • http://example.org/ is a URI
  • <a href="http://example.org/">example</a> is a link
  • when that HTML is viewed in a browser, the follow-your-nose affordance (clicking on the link to see the target representation) is provided

For RDF :

This is only for read operations - what about create, update and delete? What other affordances might there be?

Background : The question of how to build a Data Web Browser led to discussion about affordances (some additional AffordanceReferences).

Scenario 0

Oriented towards a Data Web Browser, strongly analogous to (and probably built on) a regular HTML browser. Starting with an RDF graph displayed in a window as NTriples, imagine mouseover and/or clicks providing a list of affordances

Terminology

  • component - one of self | target | triple | aux
  • self - the graph in the current window
  • target - a node appearing in self (a URI/bnode/literal)
  • triple - a statement appearing in self (also triple.subject, triple.property, triple.object?)
  • aux - auxiliary named graph(s), maintained locally or remotely (could be scratchpad. personal data store etc)

Affordances

need filling out and categorizing, rough sketch for now

better as PRECONDITIONS/POSTCONDITIONS?

maybe need INTERACTION for UI bits in between?

capability mostly determined by lookahead HEAD requests


  • Transclusion (HFactor LE Embedding links)

CONDITIONS - target GET allowed & target has a known media type (e.g. an image or RDF graph)

RESULT - representation of target displayed inline


  • Graph Replacement (HFactor LO Outbound links)

CONDITIONS - target GET allowed & target is URI & target has an RDF media type

RESULT - self replaced by graph at target


  • Node Modify

CONDITIONS - self PUT allowed (HFactor LI Idempotent links)

RESULT - edit box provided to change value of node, modified graph PUT to self URI


  • Graph Merge (HFactor LO Outbound links)

CONDITIONS - target GET allowed & target is URI & target has an RDF media type & self writable

RESULT - self becomes self + (graph at target)


...

Scenario 1

Consider a set of "levels" of affordances for a Data Web Browser. Here, three versions of clients, each with varying levels of affordance, are described.

No Affordances

In this version, no additional information is supplied w/ the resource representation. Instead, the client app "knows" the rules for adding affordances for RDF media types. IOW, the client is "hard-wired" to treat all RDF graphs in this way.

  1. Assume the entire graph is editable (HFactor LI via HTTP.PUT)
  2. Assume all URIs are navigable (HFactor LO via HTTP.GET)

The client app renders the graph representation as follows:

  1. All URIs as HTML.A-style click-able links
  2. A single button/link to turn the graph into "edit" mode
  3. A single button/link to "send" the edits to the server for processing

URI Affordances

In this version, the resource representation includes information that tells clients how to treat (add affordance to) each URI in the graph. IOW, the client detects additional information in the response (headers, links, or in-line) that instructs the client in how to render/afford the URIs.

  1. URI is a navigable link (HFactor LO)
  2. URI is a transclusion link (HFactor LE)
  3. URI is a name only (no resolution)

The client app renders the graph representation as follows:

  1. All navigable URIs are rendered as click-able links
  2. All transclusion URIs are rendered as inline content
  3. All name URIs are rendered as text

Assume this version treats the entire graph as editable (see above)

Triple Affordances

In this version, the resource representation includes information that tells clients how to treat edit-ability of triples. IOW, the client detects additional information in the response that instructs the client in how to render/afford the triples.

  1. Assume the graph is read-only
  2. The response include data on which triples are "editable"

The client app renders the graph representation as follows:

  1. Each editable triple has a link/button to turn the triple into "edit" mode
  2. When in edit mode, the client provides a button/link to "send" the edit to the server for processing.

Assume this version supports URIs Affordances (see above)

Read/Write/Query

Thinking about how to provide affordances for these various tasks. Keeping in mind not all representations of a graph need to provide all these options all the time. IOW, the goal could be to allow authors (servers) to emit representations (graphs) that provide the desired affordances appropriate for that user and for that moment in time.

  • READ navigation w/o parameters (e.g. HTML.A, HTML.LINK, etc.)
  • READ transclusion w/o parameters (e.g. IMG.A, HTML.IFRAME, X:Include, etc.)
  • QUERY w/ parameters (e.g. HTML.FORM[get])
  • WRITE non-idempotent w/ parameters (e.g. HTML.FORM[post])
  • WRITE idempotent w/ parameters (e.g. Atom rel="edit")
  • DELETE idempotent w/o parameters (e.g. Atom rel="edit")

It is possible that not all this functionality is needed for most RDF operations. For example HTTP.POST (non-safe, non-idempotent) may not be needed and HTTP.PUT can be used instead. HTML gets along fine w/ just GET and POST (w/ HEAD "under the covers").

Affordance Patterns for Sending Data

Media types handle "sending" data to servers in various ways.

  • HTML supports the "ad-hoc" pattern of an arbitrary number of data elements using the HTML.FORM to enclose one or more HTML.INPUT elements. This same affordance pattern can be used for query actions (HTML.FORM[get]) and for WRITE actions (HTML.FORM[post]).
  • Atom supports "pre-defined" pattern of a fixed set of elements defined within the media type documents (RFC4287 and RFC5023). In this case, the response representation provided to the client need not contain any direct affordances for sending data. Client apps are expected to "know" the rules outlined in the documentation and reflect this to "users" (human or bot) w/o additional hints from the payload. Instead Atom supports a method of "marking" elements to show which are "editable" (rel="edit") and noting which URI can be used to "create" (URI of the Collection). It should be noted that Atom does not support any "query" operations since there are no affordances for providing query templates within response representations.

MikeA: These are the only two patterns I can think of right now (ad-hoc, pre-defined). Are there others? Maybe other ways to "view" sending data would be better?

Use Cases

Could do with quite a few of these, at the moment things are a bit on the hoof so just dropping a link or two in as a starting point

Affordance Vocabulary

AffordanceVocabulary - a first attempt

See Also

( Web Intents - Google blog post

Retrieved from "https://www.w3.org/wiki/index.php?title=RdfAffordances&oldid=53861"