RDF Forms (original) (raw)

Introduction

RDF Forms adds to theSemantic Web, capabilities similar to those whichHTML formsadded to the early HTML based Web.

Here's a simple RDF Form;

This form is functionally similar to an HTML POST form, in that it provides the consumer such information as; the URI (the value of rdf:about) to which data can be submitted (akin to theaction attribute), the HTTP method by virtue of the rdf:type declaration of rf:Container (somewhat akin to HTML'smethod attribute, only the method is, in this case, implicitly POST), and the desired media type(s) of the data (like HTML'senctype attribute).

The end result is a declaration that the resource with URI "http://shoes.example.com/order-processor/" can accept RDF/XML submissions via HTTP POST.

Here's another different kind of form;

<rf:Indexable xmlns:rf="http://www.markbaker.ca/2003/rdfforms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" rdf:about="" title="undefined" rel="noopener noreferrer">http://shoes.example.com/unfilled-orders/"> rf:indexedBy <rf:IndexParam rf:shortName="name"> <rdf:predicate rdf:resource="" title="undefined" rel="noopener noreferrer">http://foo.example.com/param/customerFullName"/> rf:indexedBy <rf:IndexParam rf:shortName="back"> <rdf:predicate rdf:resource="" title="undefined" rel="noopener noreferrer">http://foo.example.com/param/daysBacklogged"/>

This form is functionally similar to an HTML GET form, in that it provides the client license to construct URIs using a combination of information provided by the form itself, and information provided by the client.

It begins by declaring that a particular resource is of the "Indexable" type, meaning that its URI can have parameters appended using the familiar name/value pair serialization from HTML, "?a=1&b=2&...". The remaining declarations are for the parameters, defining a "short name", used in the URI-serialization, as well as a full URI for the parameter that the client will key off of.

Other kind of forms are possible, and will be discussed below.

Specification

Containers

By declaring a resource to be of type "Container", the form publisher is communicating that the resource can accept data submitted to it for processing using generic "data submission" semantics. If the URI is a http URI, then this means that HTTP POST invocations will be accepted. Should the URI be a mailto URI, then email messages could be sent via SMTP DATA, etc.. URIs with schemes for which no analogous "data submission" semantic can be supported SHOULD NOT be used to identify Container resources.

There are two assertions made about the Container, in addition to its type. The first, "acceptedMediaType", asserts that the Container resource accepts data in a particular format, as specified by anInternet media type. This is effectively equivalent to the "form upload" feature of HTML Forms, and its "accept"attribute.

The second, "acceptedNamespace", specifies the expected namespaces. It SHOULD NOT be used with media types other than application/xml or text/xml. It's purpose is to address the problem that those media types are very commonly misused, where senders who describe their data with this type assume that recipients will be dispatching the application based on the namespace of the root element of the XML data.

HTML Forms processors support

RDF Forms also includes special support for HTML form processors, by permitting an RDF Form to declare the list of form fields. As an example;

<rf:Container xmlns:rf="http://www.markbaker.ca/2003/rdfforms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" rdf:about="" title="undefined" rel="noopener noreferrer">http://some-host.example.org/myContainer"> rf:acceptedMediaTypeapplication/x-www-form-urlencoded rf:parameterizedWith <rf:IndexParam rf:shortName="foobar1"> <rdf:predicate rdf:resource="" title="undefined" rel="noopener noreferrer">http://foo.example.com/param/foobar1"/> rf:parameterizedWith <rf:IndexParam rf:shortName="foobar2"> <rdf:predicate rdf:resource="" title="undefined" rel="noopener noreferrer">http://foo.example.com/param/foobar2"/>

When submitted, the resulting POST message will use the specified media type, plus use theencoding rules of HTMLto encode the fields in the body of the message.

Note that "parameterizedWith" is now used instead of "indexedBy". This was a change from the previous version of the spec to avoid the closed world assumption that was previously implicitly made by virtue of requiring RDF Forms software to understand the context - the type of form - in which the declaration was made.

"multipart/form-data" form processors are not currently supported.

Indexable

The second example above asserts that the identified resource is Indexable. An Indexable resource is one which logically posesses references to other resources (or possibly the resources themselves, i.e. by value), and makes them available through a query interface. This is similar to the information communicated by an HTML GET form.

The associated "indexedBy" and "IndexParam" assertions specify which properties can be used as indices, and therefore which can appear as parameters in the resulting URI.

The "rdf:resource" attribute declares the full URI of the indexing property, whereas "shortName" specifies a form-local name for the property that will be used as the parameter name in the constructed URI. "IndexParam" provides an abstraction which gives shortName its form scope (thanks to Phil Dawes for this fix).

The resulting GET message will be to a URI constructed by following theencoding rules of HTML forms; ?name1=value1&name2=value2 etc..

Settable

Settable is used to declare that the resource's state can be set explicitly. rf:acceptedMediaType can be used to declare what media types can be used to set the state. A Settable http resource is one that supports HTTP PUT. URIs with URI schemes for which no state setting action is available SHOULD NOT be used in this context.

"Form" and "method"

The following form is an alternative to the first "Container" example above;

<rf:Form rf:method="POST" xmlns:rf="http://www.markbaker.ca/2003/rdfforms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" rdf:about="" title="undefined" rel="noopener noreferrer">http://shoes.example.com/order-processor/"> rf:acceptedMediaTypeapplication/rdf+xml

Ed Note: the rf:method triple has as its subject, the rdf:about URI, in effect declaring "The resource identified by 'rdf:about="http://shoes.example.com/order-processor/' implements the POST method". However, that is not the intended interpretation of this information. The intended interpretation is that the method be considered as a descriptor of this instance of the form itself - which is why the use of rdf:type in Container/Indexable/Settable was appropriate. I can think of no concise way to represent this interpretation in RDF, and so am considering removing this section. Feedback would be appreciated.

Acknowledgements

Thanks toAaron Swartz for his RDF Schema help (since removed from the spec),Jan Algermissenfor his useful feedback and design for application/x-www-form-urlencoded support, Phil Dawes for the identification of the shortName scoping problem and its resolution,Dave Beckett for his review and feedback, andHenry Story for finding some bad RDF/XML.

RPP

WIDL

XForms; with the new "Form" element and "method" attribute, RDF Forms instances are now very similar to XForms models, although even using Container/Indexable/Settable, strong similarities exist

RESTful Web services description

Semantic Sitemaps

Notes

Future Directions

It may be useful to be able to index Indexables by a class, rather than a set of properties. For simple classes (whose property ranges are literals), this would be equivalent to indexing it by the properties of that class. For more complex classes, a more complex URI-serialization than "?name=value" would certainly be required; it would be equivalent to the problem of serializing an XML document into a URI, I think.

multipart/form-data support?

Indexing support using more than just URI query parameters. e.g. enable "http://example.org/foo/bar/\[param\]". And more generally, generative naming.

Support for alternative URI serializations

Clean up language about the relationship of URI schemes and protocols based on theTAG's investigations.

History

2003/09 - initial draft announced

2003/09/?? - added application/x-www-form-urlencoded support per Jan's design

2003/10/15 - added Phil Dawes fix for the problem whereby shortName was misused to describe the property, rather than the instance of the property in that particular form.

2003/12/09 - added XForms comparison.

2005/12/13 - removed explicit and implicit intent accomodation (missed the 80/20 point), added Settable, added "Form" and "method", added "parameterizedWith", generally simplified. The old version is still available for those that care.

--Mark Baker