Use RestWS for non-RDFa serializations and content negotiation in Drupal 7

We can also look at how Richard and Guido got conneg working for Neologism.

This makes a lot of sense. The RDF/XML it outputs needs some work, here is what it looks like:

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description xmlns:site="http://localhost/rdf-contrib/" xmlns:dc="http://purl.org/dc/terms/" xmlns:sioc="http://rdfs.org/sioc/ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:og="http://ogp.me/ns#" rdf:about="http://localhost/rdf-contrib/node/1">
    <rdf:type rdf:resource="http://rdfs.org/sioc/ns#Item"/>
    <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Document"/>
    <site:nid xmlns:site="http://localhost/rdf-contrib/">1</site:nid>
    <site:vid xmlns:site="http://localhost/rdf-contrib/">1</site:vid>
    <site:is_new xmlns:site="http://localhost/rdf-contrib/"></site:is_new>
    <site:type xmlns:site="http://localhost/rdf-contrib/">article</site:type>
    <dc:title xmlns:dc="http://purl.org/dc/terms/">Foobar</dc:title>
    <site:language xmlns:site="http://localhost/rdf-contrib/">und</site:language>
    <site:url xmlns:site="http://localhost/rdf-contrib/">http://localhost/rdf-contrib/node/1</site:url>
    <site:edit_url xmlns:site="http://localhost/rdf-contrib/">http://localhost/rdf-contrib/node/1/edit</site:edit_url>
    <site:status xmlns:site="http://localhost/rdf-contrib/">1</site:status>
    <site:promote xmlns:site="http://localhost/rdf-contrib/">1</site:promote>
    <site:sticky xmlns:site="http://localhost/rdf-contrib/">0</site:sticky>
    <dc:date xmlns:dc="http://purl.org/dc/terms/" rdf:datatype="xsd:dateTime">1303674405</dc:date>
    <dc:modified xmlns:dc="http://purl.org/dc/terms/" rdf:datatype="xsd:dateTime">1303674405</dc:modified>
    <site:author xmlns:site="http://localhost/rdf-contrib/">
      <rdf:Description rdf:about="http://localhost/rdf-contrib/user/1"/>
    </site:author>
    <site:log xmlns:site="http://localhost/rdf-contrib/"></site:log>
    <site:revision xmlns:site="http://localhost/rdf-contrib/"></site:revision>
    <site:comment xmlns:site="http://localhost/rdf-contrib/">2</site:comment>
    <sioc:num_replies xmlns:sioc="http://rdfs.org/sioc/ns#" rdf:datatype="xsd:integer">0</sioc:num_replies>
    <site:comment_count_new xmlns:site="http://localhost/rdf-contrib/">0</site:comment_count_new>
    <content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/">
      <rdf:Description>
        <site:value xmlns:site="http://localhost/rdf-contrib/">&lt;p&gt;here is the body text&lt;/p&gt;</site:value>
        <site:summary xmlns:site="http://localhost/rdf-contrib/"></site:summary>
        <site:format xmlns:site="http://localhost/rdf-contrib/">filtered_html</site:format>
      </rdf:Description>
    </content:encoded>
    <dc:subject xmlns:dc="http://purl.org/dc/terms/">
      <rdf:Description>
        <site:item xmlns:site="http://localhost/rdf-contrib/">
          <rdf:Description rdf:about="http://localhost/rdf-contrib/taxonomy_term/1"/>
        </site:item>
      </rdf:Description>
    </dc:subject>
    <og:image xmlns:og="http://ogp.me/ns#">
      <rdf:Description>
        <site:alt xmlns:site="http://localhost/rdf-contrib/"></site:alt>
      </rdf:Description>
    </og:image>
  </rdf:Description>
</rdf:RDF>

I will be posting issues in that queue for clean-up. We should move to a dependency on RestWS for all of the RDF/XML (and other serializations) as soon as we can.

Since we would have to depend on Entity and RestWS, I think it would make sense to have RDF output be a separate module in the package. This way, modules can depend on RDFx without having to enable Entity and RestWS.

The RestWS module routes all entity menu router items through its own callback, restws_page_callback, where it checks for the format extension. Because of this, there is no menu router item for the different serializations. This means that they aren't part of the menu system, so we can't create tabs for them unless we do a redirect from node/%/rdf to node/%.rdf

I think no tabs is a better solution than a redirect.

OK, here is a Turtle format for RestWS. It builds an array suitable for ARC2's Turtle serializer.

I had to move away a little bit from the algorithm used by the RDF format in two places: when the property is a multivalue field and when the property has a metadata structure that Entity preserves, as in the case of textareas. There are comments in the code that explain.

Currently there is no statement for images. I believe this is a bug in Entity's handling of image metadata, there is no URI given for the image. You'll see it is also left out in the RDF/XML above.

The patch also puts module files directly in the RDFx directory. This is how we started doing it in SPARQL module. We should probably figure out which way we want to go and make sure both packages do it that way.

Whoops, forgot to change the MIME type. Prefix.cc uses text/turtle, but I think application/x-turtle is the standard one to use.

I realized that in my haste to go get lunch, I forgot to add datatype, language, and callback.

Building the RDF model does require Entity, this implementation would be impossible without Entity... and the implementation is made much easier with RestWS. If you look at the code, you will see conditionals such as if ($property instanceof EntityValueWrapper). This is because the view function is actually a method of a RestWS class and it has Entity objects passed to it.

Entity gets the properties with their values from the database. This is definitely preferable to the way the module currently does it, because it doesn't require a switch statement and it handles the language and access controls.

There is no conneg related code necessary, AFAIK. I haven't tested it, but it seems that conneg is supposed to be a part of RestWS.

As I see it, the options are:

1. Have all of this code in RDFx and introduce the dependency on RestWS and Entity
2. Keep all this in RDF Output
3. Stick with the current way of building the model

I personally dont' see #3 as a real option. Having to use a case in a switch statement for each kind of field is not sustainable and not modular. It means that new field types cannot introduce their RDF into the model. We need to use Entity instead.

In thinking about it, we could probably extract all the model building and not have the dependency on RestWS. We would still have the dependency on Entity, but I think that's ok since a lot of modules will.

We would need to duplicate the logic from restws_property_access_filter into a function in RDFx, but it's not a very complicated a function, and implement a new version of restws_resource_uri. I think this is good anyway because we could make the resource URIs match the ones used in the RDFa.

The final version would have a function like rdfx_get_model($type, $id). That would return an array suitable for ARC2.

I can take care of detangling the model building code and move that to RDFx. Then RDF Output will just have a simple call to rdfx_get_model, which means all the different format implementations become smaller and cleaner.

Moving this to project/rdfx, the contrib RDF module's new home

Exciting! It looks good to me and will be great to have these formats and the model building code... just a few nitpicks.

+++ b/rdfx.infoundefined
@@ -4,11 +4,12 @@ package = RDF
+dependencies[] = entity

How do you handle dependency checking if RDFx is already enabled on a site? I used git to update the code on an existing site and there was no warning.

+++ b/rdfx.moduleundefined
@@ -108,456 +90,232 @@ function rdfx_help($path, $arg) {
+          // When addToTurtle is used recurssively, EntityListWrapper inserts

No longer have addToTurtle function, comment should be changed.

+++ b/rdfx.moduleundefined
@@ -108,456 +90,232 @@ function rdfx_help($path, $arg) {
+function rdfx_property_access_filter($wrapper) {

Would rdfx_property_access make sense? That seems to be the naming convention in other things, like node_access and Views' access method.

Powered by Dreditor.

I see, and RestWS uses that naming convention as well, so I guess we aren't making up our own convention at least. Makes sense to me.

Update function with message makes sense to me. We'll need to add that to this patch.

I'm testing this on a site that has entity disabled when I apply the patch. Going to update.php doesn't give me any message, it says "No pending updates". We might just need to add an empty update function to trigger the warning.

Works like a charm :)

I'm going to leave this until tomorrow to see if anyone else wants to review.

Fixed with c29136c.

I meant fixed!