Triplify

Posted by dorgon on March 16, 2008 at 10:10am

hi,

for a first simple support for RDF export, I'd like to point you to http://blog.aksw.org/2008/triplify-expose-semantics/ and http://triplr.org.
I think a quick generic RDF support for nodes will be easy to add.

I also recommend to keep the current node URI scheme and add support for content negotiation as described in [1]. So, if a client sends the request header "Accept: application/rdf+xml", the server just returns an RDF version of a node, otherwise it will get the ordinary HTML version, possible polished up with RDFa or microformat tags...

Regards,
Andy

[1] http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/

Comments

Triplify Drupal

Posted by brevity on March 18, 2008 at 12:26pm

Thanks for that! There is a first Triplify-configuration for Drupal nodes including a CCK example available:
http://triplify.org/Documentation (could include Drupal's settings.php maybe for the DB ...)

That code is sending

Posted by moshe weitzman on March 18, 2008 at 1:01pm

That code is sending unfiltered, unformatted [i.e. not run through content_format()] data to the recipients. Seems like a recipe for disaster to me. I can't think of anywhere else in Drupal that we do that.

Please contribute and help the others

Posted by dorgon on March 18, 2008 at 9:53pm

hi Moshe!

if you think sth is wrong with the code, please take time and contact the authors of triplify - it's ongoing work and it depends on the community support to be successfully at the end.

regards
Andy

Nothing is wrong with

Posted by moshe weitzman on March 19, 2008 at 12:43am

Nothing is wrong with Triplify per se. It will work for applications that store sanitized user input. We store raw user input, so it won't work securely for Drupal. I'd be happy to be proved wrong, but thats my 5 minute analysis.

New Triplify release will contain support for sanitation

Posted by soeren-gdo on March 22, 2008 at 3:30am

We are currently working on a new Triplify release, which will probably be released next week. Besides a bunch of other new features and enhancements, we already implemented support for user defined sanitation by means of callback functions, which can be defined for certain columns. If you want to have a look, please check the SVN [1] or download the next Triplify release next week.

[1] http://sourceforge.net/svn/?group_id=219253

Thanks - that is very

Posted by moshe weitzman on March 22, 2008 at 1:26pm

Thanks - that is very helpful. In various places we'll need to call:

check_markup()
check_plain()
filter_xss_admin()

privacy concerns

Posted by scor on March 25, 2008 at 2:19pm

While the concept of Triplify looks interesting, I'm concerned by the security/confidentiality aspect of it. Allowing Triplify to pull any data out of the drupal database will lead to bypass the node_access and user_access Drupal layers of access control on sites which deny public access to their users or certain nodes.

Re: privacy

Posted by soeren-gdo on March 25, 2008 at 2:56pm

As we suggest on the Triplify Website:

Please be cautious not to reveal any sensitive information. Email addresses should be SHA1 hashed, password hashes and information which is not publicly accessible should be omitted in the Triplify SQL queries. As a rule of thumb only those information should be made available trough Triplify, which are also publicly accessible on Web pages.

Of course, Triplify should only be deployed on publicly available Drupal instances. I'm also convinced you can encode the ACL within the SQL queries - for our WackoWiki Triplify configuration for example we did exactly that [1].

[1] http://triplify.org/Configuration/WackoWiki/4.2

Use cases...

Posted by Arto on March 25, 2008 at 4:01pm

Sören, I think what Stéphane is getting at is that there's little chance Triplify can provide e.g. for the fine-grained security mechanisms that Drupal can be setup with - not without duplicating the tons of actual core and add-on module code that act together to decide whether users should be allowed to access, say, a node.

Or to put it another way, the desired export behavior of a Drupal instance is not fully described merely by its database contents. Drupal is a fundamentally open-ended system, where installed add-on modules can change almost anything. So if you have, say, 100+ add-on modules installed providing complex authentication and subpartitioning of content access, Triplify will not be able to replicate Drupal's behavior without the actual code logic in those modules.

But I don't think it should even try. From the Drupal viewpoint, Triplify is a good stop-gap measure, available right here and now, for the common use cases of simple Drupal installations that contain e.g. only publicly-accessible information. It falls into the same category as the previous RDFization by the OpenLink guys. Definitely useful, but not for every Drupal use case.

The more complex use cases will be catered for by the RDF API on D6, and moving onwards, the Drupal core itself in D7.

thanks Arto for summarizing

Posted by scor on March 25, 2008 at 5:41pm

thanks Arto for summarizing my thoughts! Drupal ecosystem is too complex to be expressed in a SQL-only fashion. And even if we add some PHP logic behind, it's not sustainable when you think of all the modules willing to plug in their own access layer into the system. Eventually, we would end up reimplementing the Drupal architecture in Triplify... not the optimal way to go. The RDF API tackles the problem the other way around from the ground up within the Drupal architecture.

That said, Triplify is a great idea and allows public sites to very quickly and easily publish their data in RDF.

The more comprehensive your solution is...

Posted by soeren-gdo on March 25, 2008 at 6:49pm

... the better and Triplify might really not be suited here. However, I would like to stress our experiences regarding scalable PHP developments: from my point of view it is best to let the DB do as much as possible - especially, when ACLs and many 3rd party modules come into play I think its important to have a clean scalable interfaces, which SQL and SPARQL are. If you represent ACLs and other stuff not in the DB schema - I have serious doubts you will have a fast, scalable solution.
Anyway I really like what you are doing and I hope you will have something to submit to our Triplification challenge - from my point of view a semantified Drupal (however its done) would qualify as a winner ;-)

Triplify script for Drupal 6

Posted by davidseth on May 9, 2008 at 6:55am

I have been working on a script that works for Drupal 6. I think I have it mostly there, but would be keen to see if someone could have a look. Or if someone is even interested in having it.

The script on the triplify site works with 4.7 and 5 and when I first put it on my server I only got back 3 users. With my updated script it works much better.

Cheers,

Where can we download your configuration?

Posted by soeren-gdo on May 9, 2008 at 7:41am

I would be happy to have a look and maybe even to update the configuration on the Triplify site with your input.