Skip to end of metadata
Go to start of metadata

Correspondence with Matthias Palmer on SHAME and RForms
Matthias Palmer, Phd Student at KTH, +46(0)736812466, skype:matthias.palmer

20111018 Vlado

We're planning to use your SHAME framework for editing of complex RDF frameworks using the CIDOC CRM ontology ( for annotation of museum objects (e.g. paintings), as part of the project.
All software we produce will be open sourced. All advice/support (even if only moral support :-) will be most welcome!

20111018 Matthias

Cc: Ambj?rn Naeve; Fredrik Enoksson; Hannes Ebner; Erik Isaksson
Quick response: Sounds great! (Some developers of shame/rforms are in cc.)
It seems from the webside that you are focusing on web rather than desktop applications. In that case I would really recommend you to look at the latest code which is also renamed to RForms. You can see some documentation on the configuration mechanism here:
In short, it is a javascript library that lets you edit RDF/JSON structures (although it relies on an intermediate javascript API for RDF, so other formats could in principle be supported). The library relies on the dojo framework.
RForms is independently developed but currently resides as a subproject in the Confolio codebase. Confolio is a frontend to a RDF storage solution that is provides personal and group portfolios (often used in the context of learning).
Due to some stupid migration issues with our SVN the codebase is accessible only from this address: svn:// (We will migrate to another code hosting situation soon.)
The required libraries are in src/rforms and src/rdfjson. I am available on Skype if you want discuss things. Looking forward to hear further from you

20111018 Jana

Thank you for your prompt answer!
I've had a look at the RForms documentation and I am a little confused as I don't seem to recognize the SHAME concepts there (i.e. graph pattern model, value bindings, formlets etc).
Is this a new version or is it entirely different approach? Is there additional documentation, demos or runnable examples somewhere?

20111018 Matthias

The RForms implementation is basically a rewrite where the graph pattern, form template, and formlet has been merged into a single configuration. We hope that this approach will be easier to maintain and also easier to understand (when properly documented).
The rewrite was also done to have a real matching engine in javascript, before we relied on a server side matching step, RForms is pure javascript.

You can have a look at one of our testing environment where the configurations can be verified that they work:

It is for a EU project where profile is a variant of LOM. Another EU-project needed another profile for describing projects:

You can ofcourse also check out the code and experiment with pointing your browser to the file:///.../src/rforms/formulator/tests/voa3r.html directly.

(You might need to allow your browser to do ajax request from file:///, in firefox this is done by setting security.fileuri.strict_origin_policy = false in the about:config UI, in chrome this is done by launching with the --allow-file-access-from-files flag.)

20111019 Matthias

> I'm very happy to see that you two are hitting it off together.
> 1. We see a bunch of other projects on your confluence, would you recommend we study/try them out? Which one?

The SCAM/Confolio which is currently being renamed to EntryStore and EntryScape is highly relevant. You can experiment with an older version of confolio on: username: demo password: demodemo

Note that that installation runs the older version for editing metadata, that is, SHAME not RForms.

> 2. We got the following papers:
> SCAM Framework- Helping Semantic Web Applications to Store and Access Metadata (ESWC 2004).pdf
Not so relevant at this point.

> SHAME- Annotation Profile v1.0 (FP6 LUISA D3.2.1).pdf
Still relevant, even though the configuration mechanism has changed in RForms, the basic ideas are the same.

> SHAME- Annotation profiles- Configuring forms to edit RDF (DCMA 2007).pdf
This is a shorter more academic version of the LUISA deliverable. :-)

> SHAME- Formalizing Dublin Core Application Profiles - Description Set Profiles and Graph Constraints (MTSR 2007).pdf
The focus in this article is more on Description Set Profiles, it is an interesting initiative that our group, the KMR group, was heavily involved in. Although, since DSPs does not provide enough information for generating editors it is not so practical if you want to quickly get an RDF editor up and running. Altough if you need to formally specify an Application Profile, this is probably the way to go. Further relations between RForms and DSP (there was an initial proof of concept converter) would be interesting, although not a priority for us right now.

> SHAME- RDF modification protocol, based on the needs of editing Tools (MTSR 2007).pdf
This paper discusses the update problems you might encounter when editing RDF graphs remotely. I suggest to avoid the problems and go for a RESTful approach for updating smaller chunks of RDF, i.e. using named graphs, more on that in next mail to Jana.

> Would you recommend we read something extra?

Well, depends if you want walk the academic road or the developer oriented road. There is always the recently published licentiate thesis by Fredrik Enoksson that deals with Shame:

20111019 Jana

Hi Matthias! I got the code and had a look into it. I also ran the examples.
I have a few questions.

  • How do we load existing data (that is going to be edited)?
  • How do we save changes (in literal values, new/deleted nodes etc.)?
  • How do we provide values for choice elements, based on ontology (and not hardcoded)?

And another important question. There was a mentioning in an article about SHAME that it should be possible for the layout elements to represent arbitrary parts of the graph.
For example, if we have the following triples:
Publication->Author->Date of birth
We should be able to represent/edit just publication's title and author's date of birth in GUI, skipping author node altogether from showing.
As far as I got it, this was achieved by the so called graph pattern (a QEL query that selects certain parts of the graph).
I am not sure whether RForms has the same functionality?
We are currently evaluating different approaches to implementing our GUI. If decide to go with RForms and if you don't mind, we will be glad to give you a hand on coding. After we get enough knowledge on its internals, of course. :)

20111021 Matthias

We will take your interest as a motivation to extract rforms into an own project on google code. I will get back to you shortly on this
Just want to let you know of some improvements on Google code,

  1. It is now easy to checkout and build.
  2. There is some documentation, including the beginnings of a tutorial with inline running examples and a experimental interface where you can write your own RForms-template on the fly.

Comments or questions are of course very welcome.

20111021 Jana

Great! Thanks a lot!
I am still not really sure how do we save edited/new data. To be honest, I did not quite find anything about it in the SHAME articles as well.

20111021 Matthias

Ah, this is one part I have not documented yet on the google code page, there is only a placeholder. But I give you some pointers here.
First of all, neither RForms or the older SHAME library contains any storage mechanism. Both libraries relies on a separate solution for storing the RDF. Such a storage solution is typically based on a triplestore. The RForms library would then integrate/connect to this storage solution some way. Here are two possible ways:

  1. A traditional Web1.0 approach would use something like JSP to generate webpages which sometimes contains the RForms editor. When it is time to save the edited RDF the updated data is simply inserted into the POST.
  2. A more modern Web2.0 approach would expose the repository using a RESTful approach with separate URLs for each metadata record. The RForms editor is triggered on a specific metadata record, fetches it using an XHR GET request, updates the editor, and on save it does a XHR PUT on the corresponding metadata record without reloading the page the editor is on.

If you are interested in finding solutions for storing metadata on a server we are developing EntryStore (formerly SCAM) to fill this role. See for more details. We also have the EntryScape (formerly Confolio) which is a personal portfolio user interface that exposes much of the functionality of the EntryScape respository. EntryScape is already integrated with RForms for metadata presentation and editing.

There are other alternatives for storing metadata for instance use the cloud storage provided by Talis, although I have not tested this myself. You can of course build everything yourself, perhaps on top of a triplestore such as Sesame. Maybe support something like: (What EntryStore offers is close, and will probably support this initiative whenever it gets more mature.)

Just to be clear, if you need more advanced management of metadata records, supporting access control, harvesting etc. Then I would really recommend you to use some existing solution as it is a lot of work.

I will try to provide a more well thought through documentation on this in the wiki on google code soon.

Maybe it would be useful to have a conversation over skype soon, perhaps more efficient?

PS. It might be useful for you to know that there is also commercial support around the opensource solutions RForms, EntryStore or EntryScape. For instance if you do not want to do specific adoptions yourself or you want someone to host the system for you, we have a separate company that can help you with this: MetaSolutions AB, see

20111021 Matthias

> How do we load existing data (that is going to be edited)?
Depends on how you use the library.

If you generate an html page you could have the RDF inside a script tag and then generate the presentation/editor by running the rforms code on that part. See src/rforms/view/tests/editorView.html There both the template and graph is javascript object that are loaded by dojo's load system, but they could easily be replaced with inline javascript objects.

But you could also fetch and when finished save data using AJAX calls.
I guess it depends on wether you have a RESTful approach to managing
your RDF or not.

> How do we save changes (in literal values, new/deleted nodes etc.)?
RForms works with the RDF/JSON format:

RForms also comes with the rdfjson library that can be used to programmatically manage the RDF in the client. RForms uses this API internally. The best approach would be if you had a service which allowed you to work with RDF/JSON using HTTP GET and PUT, i.e. a RESTful service. If you stick with RDF/XML I think it would be nice to include support for parsing from RDF/XML into the API we already have. There are already javascript parsers that we could rely on.

> How do we provide values for choice elements, based on ontology (and not hardcoded)?

In Shame we had a service for generating the choice elements from RDFS/OWL by applying the Graph Pattern + Form-template. We plan to break out this service and include it into the RForms library. But yes, it will most probably have to be a server side service since you do not want to do this in javascript.

> Publication->Author->Date of birth
> We should be able to represent/edit just publication's title and author's date of birth in GUI, skipping author node altogether from showing.
> As far as I got it, this was achieved by the so called graph pattern (a QEL query that selects certain parts of the graph).

This should be possible in RForms as well, I am not 100% that it is fully tested though. Will have to check this.
Overall, the aim is to have equal or more functionality than SHAME had.

20111021 Vlado

Our forms will need several modes, e.g.:

  • read-only
    • Will be the default since art researchers don't directly edit painting data, they propose a new version for a particular field, and comment/justify extensively.
      Matthias: RForms has a presentation view.
    • Preferably, should be optimized to emit plain html (static text), not emit html controls that are then disabled using DOM
      Matthias: If you are fine with something generated on the client side, yes. RForms is a client side javascript. If you need to have something rendered already on the server side you could always run the RForms library using nodejs. You could also rely on the older Shame java code, it had support for the new rforms configuration mechanism before we shifted our attention to the javascript library. It has not been tested exetensively for some time though.
  • editable
    • Edit controls for existing fields are activated on a per-field basis
      Matthias: You mean something like click to edit an individual field rather than switching the entire form into edit mode?
      We do not have this currently, but it is certainly doable, I would say less than a week of work effort (probably less).
    • If the researcher wants to add a complete new node, all new subnodes are editable
      Matthias: Yes, this is how it works now.
  • printable (not in current scope, but close)
    Matthias: I think this works already, some css changes to get it nicely displayed in print view would be nifty though.
    • Similar to read-only, but includes all text:
    • all nodes are expanded (if we use collapsing), or
    • all sections are rendered (if we use partial-section rendering)
      Matthias: The presentation view currently shows everyting, we only have collapsing in the edit mode currently. Partial sections can certainly be done, the presentation view is the easiest to modify or create alternative views from.

If we adopt RForms, we'll think how we could make such extensions reusable.

  • Matthias: Great, in any case I use your interest to ignite some energy into doing some long overdue overhawl of the project documentation and structure.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.