The Semantic Web is currently missing two key features of the hypermedia application model which are prevalent on the browser based Web; the ability to declare the intent of a resource to receive data for processing, and the ability to use data as arguments in the client-side construction of a URI. RDF Forms addresses these two needs in a manner similar to how HTML forms addresses them for the current Web.
The following are considered the key concepts and contributions of RDF Forms;
Consider this a working draft. I'm just "putting it out there" to solicit feedback and gauge interest.
Subsequent versions may undergo backwards-incompatible changes. If you want to write code using this, please let me know.
This is one possible serialization of a data submission form (aka POST form);
<rf:Container xmlns:rf="http://www.markbaker.ca/2003/rdfforms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
rdf:about="http://shoes.example.com/order-processor/">
<rf:acceptedMediaType>application/xml</rf:acceptedMediaType>
<rf:acceptedNamespace rdf:resource="http://shoe-standards.example.org/orders/shoes/"/>
<rf:intent rdf:resource="http://shoe-standards.example.org/order-shoes/"/>
</rf:Container>
And this is one possible serialization of an indexing form (aka GET 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="http://shoes.example.com/unfilled-orders/">
<rf:indexedBy>
<rf:IndexParam rf:shortName="name">
<rdf:predicate rdf:resource="http://foo.example.com/param/customerFullName"/>
</rf:IndexParam>
</rf:indexedBy>
<rf:indexedBy>
<rf:IndexParam rf:shortName="back">
<rdf:predicate rdf:resource="http://foo.example.com/param/daysBacklogged"/>
</rf:IndexParam>
</rf:indexedBy>
</rf:Indexable>
The first example above starts by asserting the key triple;
<http://shoes.example.com/order-processor/> rdf:type <http://www.markbaker.ca/2003/rdfforms/Container>
This statement is one way that an RDF Forms enabled agent can infer that the "order-processor" resource accepts data (though it may also be done implicitly, as well as via vocabulary specific means, though that defeats much of the benefit of RDF Forms). If the URI is a http URI, then this means that POST invocations will be accepted. Should the URI be a mailto URI, then email messages could be sent, etc.. URI schemes for which no "data submission" semantic exists SHOULD NOT be used to identify Container resources.
There are three 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 an Internet 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 root namespace of the XML data.
The third, "intent", is is used to indicate any "extended intentions" that the corresponding data submission message should have, beyond those of simple data submission. "intent" has identical semantics to SOAPAction of SOAP 1.1, and the SOAP action feature of SOAP 1.2. If an intent is declared, the data submission request MUST include it. As not all protocols include support for it, including vanilla (non-extended) HTTP, "intent" SHOULD NOT be used when the protocol being used does not permit any extended intentions to be declared. Currently, that means only using it with SOAP 1.1 or SOAP 1.2 together with an underlying application protocol which supports data submission, such as HTTP or SMTP. Future protocols, such as Waka, are also expected to support it.
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="http://some-host.example.org/myContainer">
<rf:acceptedMediaType>application/x-www-form-urlencoded<rf:acceptedMediaType>
<rf:indexedBy>
<rf:IndexParam rf:shortName="foobar1">
<rdf:predicate rdf:resource="http://foo.example.com/param/foobar1"/>
</rf:IndexParam>
</rf:indexedBy>
<rf:indexedBy>
<rf:IndexParam rf:shortName="foobar2">
<rdf:predicate rdf:resource="http://foo.example.com/param/foobar2"/>
</rf:IndexParam>
</rf:indexedBy>
<rf:Container>
When submitted, the resulting POST message will use the specified media type, plus use the encoding rules of HTML to encode the fields in the body of the message.
"multipart/form-data" form processors are not currently supported by RDF Forms.
It is also possible to declare the intent implicitly rather than explicitly using the intent property. For example, consider the following RDF snippet;
<myns:SmsMessageReceptor xmlns:myns="http://my.example.org/messaging/"
rdf:about="http://some-telco.example.org/sms-sender/">
<rf:acceptedMediaType>text/plain</rf:acceptedMediaType>
</myns:SmsMessageReceptor>
Here, it isn't obvious what it means to have SmsMessageReceptor use the acceptedMediaType property. However, due to the fact that rf:acceptedMediaType is declared to have an rdfs:range of rf:Container, an RDF Forms processor can infer that myns:SmsMessageReceptor is an rdfs:subClassOf rf:Container, and therefore of rdf:type rf:Container.
But because the form was declared using the more specific type, there exists an implicit intent that the client is interacting with that specific type and not just any Container. Therefore, "http://my.example.org/messaging/SmsMessageReceptor" can be said to identify the extended intent of this interaction, and an RDF Forms processor MUST attempt to communicate this in the data submission request as described above.
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 do all the work; they 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-local scope (thanks to Phil Dawes for this fix).
The resulting GET message will be to a URI constructed by following the encoding rules of HTML forms; ?name1=value1&name2=value2 etc..
Sometimes, perhaps often, the declaration that a resource is of type rf:Container or rf:Indexable is made somewhere different than where the accept* or indexedBy assertions are made. In these cases, the RDF Form processor MUST infer from the fact that the rdfs:Domain of the RDF Forms properties is either rf:Container or rf:Indexable, that the resource is of rdf:type rf:Container or rf:Indexable; rf:indexedBy implies a rf:Indexable, and rf:acceptedMediaType, rf:acceptedNamespace, rf:intent, and rf:acceptsField imply type rf:Container
Note that this requires that RDF schema inferencing be used by RDF Forms processors.
Thanks to Aaron Swartz for his RDF Schema help, Jan Algermissen for 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), and to Dave Beckett for his review and feedback.
XForms; if XForms were done in RDF, gave everything a URI, and broke from the general "form" container to the Container & Indexable abstractions, it would look a whole lot like RDF Forms.
Error handling needs a lot more thought.
Is implicit intention worth bothering with? I think the model is pretty good, but certainly underspecified. See error handling.
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
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.
--Mark Baker