Re: relational data as a bona fide member of the SM

On 2011-11-12, Toby Inkster wrote:

> Strikes me that N3 and SPARQL could be extended with some pretty 
> simple syntactic sugar to get this done.

Somehow SPAQRL strikes me as being somehow unclean. Just as SQL does, 
even as that one pays may rent. N3 on the other hand...there I'll have 
to yield. It really does do what I was talking about, with its 
semicolons and commas, amongst (I for once hope) a LALR parsable 
grammar. Thus very cool; my example would go *years* back, but I think 
it's still there: just take a look at the .n3's in here, from the time: .

But really, triple-fu or just sugar ain't my points. The real beef in is 
establishing a stable, true isomophism between the relational model, and 
the RDF one. I'm actually rather certain there can be only one. Simply 
because of the axiomatic semantics of both.

My particular favourite pivot in the (partial) isomorphism I've been 
able to come up with is how object identifiers (from an 
object-relational mapping/ORM), the surrogate keys we get from RM/T or 
RM/V2, and then blank nodes in the RDF world, all map to the very same 
thing. Beautifully. While all being the-most-feared-subjects within 
their respective realms.

All of that actually maps one-to-one onto RM/T, with a single null 
"value". Backwards it's even simpler. (Though you do have to notice the 
difference between actual and reified tuples. In RM that's all implicit 
in the semantics of a given relation, and the logical consistency 
requirements it has wrt other relations. In RDF/EAV, you reify, giving a 
number of tuples which wtill could be checked and analogized even in 
reified form using, say, tableaux. So yeah, you have to be careful when 
you go from one model to the other; but it can be done, and really, I 
think there is only one way, leading to essentially an isomorphism 
between the two.)

> When parsing, if the relationship identifier is encountered, the 
> parser consumes this, and then consumes an RDF list, but rather than 
> adding the list to the graph, it interpolates the classes and 
> properties.
>    JOB("Bee Keeper" "W3C")
> is treated as:
>    [ a j:Job, j:Employment; j:title "Bee Keeper"; j:employer "W3C" ]

And in its relational implementation,

(j:Job, j:Employment)
(j:Job, j:Employment, j:employer)
(j:Job, j:Employment, j:title)

(The best that I can do absent further data. But perhaps that makes it 
clear that you can use URI's as keys even within the relational model, 
and that actually relational normalization theory applies whther or not 
your triplify your data.)

> An extended version of SPARQL (SPARQL-R, say) could include a similar 
> facility.

Perchance should.


Will read.

My own mental playing ground has to do with the relational model. For 
example, every image is obviously a function from a 2D space to a 3D 
one. Encode that, and what those five axes mean, and you're go. Video? 
sure, it's just one axis more on the left-hand-side. Compression? Fine. 
Let's just give the codec as metadata, and say "it still yields the 
usual 1D+2D+3D video", with appropriately named axes which we know how 
to interpret.

As one of my friends aptly put it, that ain't exactly rocket surgery.

> This certainly seems like a useful idea, and I'd be happy to 
> experiment with something along these lines.

Please do. I on the other hand don't, because I'm a theoretician. I 
know. You go and implement. (And I'm pretty sure you've seen much of 
that mindset over the course of the development of even the basic RDF.)
Sampo Syreeni, aka decoy -, 
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0

Received on Friday, 18 November 2011 08:06:16 UTC