Talia Meeting Six

Status Reports

Michele completed the ActiveRDF changes for triple deletion and the handling of multi-value properties (see #62). Inverse lookups are also possible (#202) but need a little fix (#238). We still need to research how the Source types will be represented in ActiveRDF (#208). Michele also fixed the non-working LIMIT and OFFSET parameters in ActiveRDF (#223 #224). There is also a Rake task to import ontologies (#209)

Daniel moved the changes from ActiveRDF to the Source class: There is now a find/query mechanism for the query (#203), however it will still need some work, as well as support for OR queries (depending on ActiveRDF). The Source class also wraps the new ActiveRDF PropertyList now, so that a property can now have multiple values.

Daniel has started on working on the type system interface (#208) - the complete implementation has to wait until the ActiveRDF issues are resolved. He didn't yet start the GUI plugin (#175)

Luca presented two new plugins he create: One was for the REST client library, and allowed to create classes that will act as ActiveResources but can use multiple REST endpoints (instead of a single endpoint per class, as in "normal" ActiveResource). This will be needed for a REST client that can connect to different TaliaNode servers.

The other plugin was a supercool addon for Globalize and was much discussed during the meeting. It should make the translator's job a breeze...

RDF and SQL sync disucssion

There was also a discussion about the "synchronization" of the database - see RdfDbSync. It was decided that Sources will not be saved on creation. Rather, the Source class will throw an error when an RDF triple is added before it was saved. We also discussed if this relaxed model would be enough, or if we needed consistency checking, rollback or full ACID support on the RDF store. We decided that while these features would be nice, they are difficult to implement.

At the moment will assume that each RDF triple is valid on it's own, regardless of the state of the SQL record or other triples. If we need the more advanced features, the respective data should be stored in the database.

Prototype/GUI discussion

There was a discussion with Giulio and Michele B. about the GUI and the prototype. This resulted in the following new specifications/changes:

• Michele needs a valid HTML "document" with <div> and other tags, so that he can show a browser-based annotation prototype based on annozilla. The "documents" for the prototype will therefore be HTML fragments.
• The sidebar in the prototype will contain several tabs (one for the source classes and one for the contextual information at least)
• There will be a "mockup" toolbar, so the users can see all the main elements of the interface

Next steps

• Michele N. will check the type information in ActiveRDF. If sub/supertypes cannot be supported easily, we may have to move the functionality to the Talia core.
• Luca will finalize the REST controller after being unblocked by Daniel
• Daniel will start the UI framework
• After the UI framework is in place, we will assign the rest of the tasks to the team
• Daniel will also work with Giulio on the page layout/integration
• Guilio will create a prototype layout in the next two weeks.

Next meeting

Michele and Christian will meet one week before the Rome meeting. We will make this a full Talia meeting, so that we can fix the last issues on the prototype before it is presented.