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

Hi Adrian,

Indeed, you may have a performance challenges no matter what convention
you use.  What other solutions are you considering or using?  And can
you tell us a little more about the use cases that you have in mind?  

Thanks,
David

On Sat, 2011-11-12 at 15:05 -0500, Adrian Walker wrote:
> 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.
>         
>         
> 

-- 
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:54:02 UTC