[TripleStore] Re: SWAD-Europe Report: Mapping Semantic Web Data with RDBMSes

[Jean-Michel Hiver]

> > For example, in my limited understanding of RDF, an identifier is
> > necessarily a URI. TripleStore doesn't enforce that.
> 
> RDF triple parts (nodes) are URI-references or Literals or local
> identifiers and the URL I gave you defines the types of all of those.
> 
> 
> > If you have the Perl structure:
> > 
> >   my $hash = {
> >     address => {
> >       street => '1501 Grant Avenue',
> >       state  => 'Massachusets',
> >       city   => 'Bedford',
> >       zip    => '01730',
> >     }
> >   };
> > 
> > You can insert:
> > 
> >   $store->insert ('_id:1', 'address', '_id:2');
> >   $store->insert ('_id:2', 'street', '1501 Grant Avenue');
> >   $store->insert ('_id:2', 'state', 'Massachusets');
> >   $store->insert ('_id:2', 'city', 'Bedford');
> >   $store->insert ('_id:2', 'zip', '01730');
> 
> You can, but those are all strings.

Well, yes and no...

The way I thought about solving this issue is the following: if you see
something that looks like an identifier, then make a query on the triple
store to see if that identifier exists...

If it exists, then it's a node, if it doesn't then it's a string.

Plus you can 'use overload;' to make Perl objects look like strings
when used in string context.


> Still strings.
> 
> If you want to interpret some of the strings as URIs / RDF literals /
> bnodes etc. , that would be an extra layer above or maybe you can
> store real perl objs? such as new URI("http://example.org/"), new
> localID('_foo') etc.  (Without using Storable or Freeze/Thaw which are
> a bit of a hack)

I don't want to use Freeze/Thaw because then things are not properly
queriable anymore. So I might as well try to do it properly.

(let's get a bit technical...)

At the moment the underlying data structure is a very simple table that
looks as follows:

table TRIPLES
=============
  S_NUM        DOUBLE
  S_STR        BIGTEXT
  
  P_NUM        DOUBLE
  P_STR        BIGTEXT
  
  O_NUM        DOUBLE
  O_STR        BIGTEXT

So, two columns for subject.

When you insert ($foo, $bar, $baz), $foo is inserted as "$foo" (string
context) and as 0 + $foo (numeric context).

Are you saying that there are more contexts that I should take into
account?

That maybe I should have a 'triple context' and hence the table would
become:

table TRIPLES
=============
  S_NUM        DOUBLE
  S_STR        BIGTEXT
  # subjects cannot be triples...
  
  P_NUM        DOUBLE
  P_STR        BIGTEXT
  P_TPL        BIGTEXT
  
  O_NUM        DOUBLE
  O_STR        BIGTEXT
  O_TPL        BIGTEXT
  
?


> > I understand that you loose the shared vocabulary though...
> 
> ?

Well, for example if you use 'creator' instead of the dublin core URI
for 'creator', you don't stick to a predefined standard anymore. But
it's faster to type :)


> It is a layering thing; you lose the URIs/literals distinction.  Or
> consider it as datatypes.  Perl automatically de/stringifys things
> without you thinking about it but that loses the typing information.

Ok, so you think that URIs should be different datatypes. Fine.

Maybe URIs and LocalIDs could be collapsed into the same datatype, which
could be called 'Reference'.

Then maybe to insert reference the 'insert' syntax could become:

  $store->insert ('_id:1', 'address', \ '_id:2');

Do you think that'd be OK? The more I think about your remarks the more
I realize this maps even better the object model than just litterals. I
started with just Strings / Numbers but adding references seem to make
sense.


> Maybe you could look at some of the perl code I have for my Redland
> system
> 
>   http://cvs.ilrt.org/cvsweb/redland/librdf/perl/lib/RDF/
> 
> or the RSS library I have, which is more application level and shows
> how the triple-based interfaces are used:
> 
>   http://cvs.ilrt.org/cvsweb/redland/librdf/perl/lib/RDF/Redland/RSS.pm?rev=1.24
> 
> All my Redland demos are done in perl, so I'm very familiar with it.

Allright, I'll do it now :)

Cheers,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver at mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/