Re: N-ary relations [was Re: relational data as a bona fide member of the SM]

Hi David,

That certainly looks neat.

In practice, N-ary relations often have arities in the hundreds.

What are the performance considerations of making each row of a 100-ary
relation a list?  Of 'joining' two such list-tables on an attribute at
positions 50?

                          Thanks,  -- Adrian

Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over SQL
and RDF
Online at www.reengineeringllc.com
Shared use is free, and there are no advertisements

Adrian Walker
Reengineering

On Sat, Nov 12, 2011 at 2:03 PM, David Booth <david@dbooth.org> wrote:

> Hi Toby,
>
> Extending the syntax may be useful in some cases, but bear in mind that
> there is no actual need to extend the syntax in order to enable n-ary
> relations to be recognized in RDF.  They can simply be tagged as being
> n-ary relations, provided that standard n-ary-relation-tagging URIs have
> been defined.
>
> For example, here is one way to do it using lists:
> [[
>  @prefix foaf:   <http://xmlns.com/foaf/0.1/> .
>  @prefix std:    <http://standards.example.org/Nary#> .
>  @prefix :       <http://example.com/job#> .
>  @prefix person: <http://example/person#> .
>
>  ####### Using list style with positional elements:
>  :job a std:NaryRelation .
>
>  person:joe foaf:name "Joe Bloggs" ;
>    :job ( "Bee Keeper" "W3C" ) ;
>    :job ( "Senior Vice-President" "CompuGlobalHyperMeganet" ) ;
>    :job ( "Polar Bear Wrangler" "DHARMA Initiative" ) .
>
> ]]
> This style has the benefit of brevity.
>
> And another way to do it using classes:
> [[
>  @prefix foaf:   <http://xmlns.com/foaf/0.1/> .
>  @prefix std:    <http://standards.example.org/Nary#> .
>  @prefix :       <http://example.com/job#> .
>  @prefix person: <http://example/person#> .
>
>  ####### Using class style with bnodes and named elements:
>  :Job a std:NaryRelationClass .
>
>  person:jen foaf:name "Jen Bloggs" ;
>    is :employee of
>      [ a :Job ;
>        :title "Bee Keeper" ;
>        :employer "W3C" ] ,
>      [ a :Job ;
>        :title "Senior Vice-President" ;
>        :employer "CompuGlobalHyperMeganet" ] ,
>      [ a :Job ;
>        :title "Polar Bear Wrangler" ;
>        :employer "DHARMA Initiative" ] .
> ]]
>
> One key thing that this would enable is that an RDF store that knows the
> semantics of std:NaryRelation or std:NaryRelationClass would be licensed
> to eliminate duplicate triples -- triples that it otherwise may not be
> able to recognize as duplicates, because of those pesky bnode.  (Lists
> automatically create bnodes, so both examples use bnodes.)
>
> To further explain for the benefit of other readers who may not be so
> familiar with the semantics of RDF lists, this statement:
>
>  person:joe :job ( "Bee Keeper" "W3C" ) .
>
> actually means:
>
>  person:joe :job _:b1 .
>  _:b1 rdf:first "Bee Keeper" ; rdf:next _:b2 .
>  _:b2 rdf:first "W3C" ; rdf:next rdf:nil .
>
> and if that is read in twice to an RDF database then you may get it
> appearing twice (with different bnodes) in your data:
>
>  person:joe :job _:b1 .
>  _:b1 rdf:first "Bee Keeper" ; rdf:next _:b2 .
>  _:b2 rdf:first "W3C" ; rdf:next rdf:nil .
>
>  person:joe :job _:b3 .
>  _:b3 rdf:first "Bee Keeper" ; rdf:next _:b4 .
>  _:b4 rdf:first "W3C" ; rdf:next rdf:nil .
>
> because the RDF list semantics
> http://www.w3.org/TR/rdf-mt/#collections
> does not say that either of those entails the other.  In other words, it
> would be as though the exact same n-ary relation were appearing twice in
> your database:
>
>  person:joe :job ( "Bee Keeper" "W3C" ) .
>  person:joe :job ( "Bee Keeper" "W3C" ) .
>
> and that is *not* what one would want.  The ability to recognize :job as
> a std:NaryRelation would enable the RDF store to avoid storing duplicate
> assertions like this.
>
> So personally, although a new syntax may be useful sometimes, I think it
> is more important to standardize a semantic tag that would allow n-ary
> relations to be recognized with or without a special syntax.
>
> Thanks,
> David
>
>
> On Sat, 2011-11-12 at 01:42 +0000, Toby Inkster wrote:
> > On Thu, 3 Nov 2011 09:57:08 +0200 (EET)
> > Sampo Syreeni <decoy@iki.fi> wrote:
> >
> > > As a relational minded guy, I wonder why there aren't any genuinely
> > > relational minded formats/syntaxes/data around
> >
> > Strikes me that N3 and SPARQL could be extended with some pretty
> > simple syntactic sugar to get this done.
> >
> > #### employment_history.n3x ###########################
> > @prefix j: <http://example.com/job#> .
> > @relation JOB; j:Job, j:Employment; (j:title j:employer) .
> >
> > <#joe>
> >   foaf:name "Joe Bloggs" ;
> >   is j:employee of
> >     JOB("Bee Keeper" "W3C") ,
> >     JOB("Senior Vice-President" "CompuGlobalHyperMeganet") ,
> >     JOB("Polar Bear Wrangler" "DHARMA Initiative") .
> > #######################################################
> >
> > The "@relation" directive would establish a relationship identifier. (In
> > the above case, "JOB".) Relationship types take a set of classes (above,
> > j:Job and j:Employment) and a list of properties.
> >
> > 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" ]
> >
> > An extended version of SPARQL (SPARQL-R, say) could include a similar
> > facility.
> >
> > I've been playing with extending N3 syntax:
> >
> > http://www.w3.org/wiki/ShorthandRDF#RDF-TriN3_Implementation
> >
> http://goddamn.co.uk/svn-web/perlmods/view/RDF-TriN3/examples/vcard_ttl.pl
> >
> > This certainly seems like a useful idea, and I'd be happy to experiment
> > with something along these lines.
> >
>
> --
> David Booth, Ph.D.
> http://dbooth.org/
>
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of his employer.
>
>
>

Received on Saturday, 12 November 2011 20:06:11 UTC