Semantic Overflow

Question

6

3

I'm under increasing pressure to start using RDF as a back-end for websites, rather than MySQL.

I've been considering the basic "patterns" of use, generally they boil down to create item, delete item, update item, get-from-id, get-items-matching-x.

In MySQL, when creating an item, we use an AUTO_INCREMENT field to be sure we get a unique ID. Is there a reliable way to do this with a triple-store as a backend?

I don't want to generate UUID's (although thanks for the suggestion), we often need to expose primary keys in URLs. eg: http://foobar.com/news/134.html I don't want to have to use: http://foobar.com/news/12Ef0023-F238EbA673CAA38-F34.html It's not user-friendly.

edited Feb 5 at 9:05

Bastian Spanneberg
1,057●1●9

asked Jan 31 at 10:20

Christopher Gutteridge
519●8

	I've also been discussing this on our blog; blogs.ecs.soton.ac.uk/webteam/2010/02/02/… I think this is all part of normal growing pains of a new technology. – Christopher Gutteridge Feb 3 at 13:54
	Which academics in particular are pushing this? – Rob Vesse Feb 4 at 17:16
	Just a few thoughts about solutions to your particular problem (which btw got me thinking a lot – so thx), but not an answer to your question (!): create locally unique ids (in a php application, we need to use some persistence/state-enabling technology like -- haha – MySQL) and build your urls around these. Alternatively, create rdf with these ids as values and create a "pretty url" (i.e. this.no/ids/123) wrapper for a SPARQL query that queries these ids, leaving the triplestore-generated urls intact. – brinxmat Feb 5 at 14:54
	@brinxmat; we're IT pros working with fluffy researchers. It's good fun; we try to turn the impossible into business-as-usual. Sometimes it works. It's worth asking the dumb questions as sometimes one person happens to have the obvious answer and the world gets a little better. @Rob Vesse; that is not an appropriate question in a technical forum. – Christopher Gutteridge Feb 6 at 1:43
	@Christopher Gutteridge: do tell us if you solve your problem. – brinxmat Feb 7 at 16:57

Jerven · Answer 1 · 2010-02-03 08:22:47Z UTC

When using virtuoso you can use the fact that it is also a rdbms to use its internal atomic sequences. With something like this.

SPARQL INSERT INTO GRAPH <http://mygraph.com> {  
        <:a>
        <:p>
        sql:sequence_next("GRAPH_IDENTIFIER") };

See http://docs.openlinksw.com/virtuoso/sequenceobjects.html and http://docs.openlinksw.com/virtuoso/rdfsparql.html#rdfsqlfromsparql

To be honest I have not tested it yet. I will try this tonight. In practice you might need to do a separate select for key and then insert later as you might need the key directly in your front-end application.

dpinn · Answer 2 · 2010-02-02 13:10:08Z UTC

1

By 'a reliable way' do you mean 'a way that makes the data store enforce it natively'? If so, then I believe that the answer is No.

edited Feb 2 at 13:10

answered Feb 2 at 13:01

dpinn
119●6

You're right about "reliable". There are different ways of achieving this in different stores. Not sure that I'd use any of them. – brinxmat Feb 3 at 9:59

Pierre · Answer 3 · 2010-01-31 12:44:43Z UTC

0

Here are some links that might give you some ideas:

http://infolab.stanford.edu/~melnik/rdf/db.html : Storing RDF in a relational database (2000)
http://www.w3.org/2003/01/21-RDF-RDB-access/ RDF Access to Relational Databases

answered Jan 31 at 12:44

Pierre
155●2

Utterly the opposite of what I asked. I want to know how to STOP using a relational database and use an RDF backend instead. – Christopher Gutteridge Feb 1 at 15:21

Vasiliy Faronov · Answer 4 · 2010-02-01 23:16:14Z UTC

0

Just an idea: how about GUIDs? I hear they are increasingly common in the RDBMS land as well. Maybe they are more expensive to produce and locate than integers, but you don’t have to care about concurrency.

answered Feb 1 at 23:16

Vasiliy Faronov
223●7

1

You mean UUID (a standard; GUID is MS' implementation of this) :) – brinxmat Feb 3 at 9:33

I've looked into these abut they are not URL-friendly. If I want to generate URLs humans could read out, 32 Hex chars ain't friendly! – Christopher Gutteridge Feb 3 at 13:52

brinxmat · Answer 5 · 2010-02-04 21:59:04Z UTC

0

Is this necessary? I would assume that each triple's dereferencable URL would be a unique (though not necessarily incremented) id :)

This approach allows you to abstract away from the storage.

edited Feb 4 at 21:59

answered Jan 31 at 12:39

brinxmat
269●7

That in no way actually answers my question. I want a system to generate reliable unique IDs. This is essential and must be robust. It's important to never ever have 2 parallel web requests attempt to create a record of the same ID. – Christopher Gutteridge Feb 1 at 15:20

2

Um. No (well, the url bit did ;) ). Here's the talis approach n2.talis.com/wiki/Primary_Key_Pattern – brinxmat Feb 1 at 21:06

After reviewing more literature: several triplestores have their own solution for generating unique ids, there are links to some of these in the other posts. In order to achieve what you want, you're going to have to create some application logic that locks the triple that is being edited based on some triple-internal identifier/the triple's url. There are several suggestions as to how ids can be generated in the other answers. – brinxmat Feb 3 at 9:57

Abstracting away from the storage is fine, but the next-value-in-sequence is part of the state of my data, therefore requires storage, backing up and access/modification rights management. – Christopher Gutteridge Feb 3 at 13:58

Brinxmat, thanks for the Talis link. It's just as evil as the SQL solutions! – Christopher Gutteridge Feb 5 at 10:26

Generating unique ID’s in triple-store, ala MySQL AUTO_INCREMENT

5 Answers