W3C home > Mailing lists > Public > public-rdf-wg@w3.org > December 2011

Re: [ALL] agenda telecon 14 Dec

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 14 Dec 2011 15:32:14 -0600
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-wg@w3.org
Message-Id: <33F9D4C2-AB48-42C9-983C-7561D2A3AB67@ihmc.us>
To: Dan Brickley <danbri@danbri.org>

On Dec 14, 2011, at 10:23 AM, Dan Brickley wrote:

> On 14 December 2011 09:25, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
>> 
>> 
>> On 13/12/11 22:20, Dan Brickley wrote:
>> 
>>> It's tempting to try to use this standardisation opportunity to
>>> squeeze something like Gremlin/Tinkerpop's 'Property graphs" into RDF,
>>> ie. something like
>>> https://github.com/tinkerpop/gremlin/wiki/Defining-a-Property-Graph in
>>> which graph edges are decorated with little extras. But I can't really
>>> see a route to getting there...
>>> 
>>> Dan
>>> 
>> 
>> That would be an n-ary property, with two of the parties of the n-ary
>> relationship slightly distinguished as subject and object? (not sure they
>> are distinguished - it might be just the way you look at the graph)
> 
> Yes this is the most interesting design point.
> 
> When you talk to people about RDF, only having binary relations often
> causes frustration. There's a desire to qualify relations in various
> ways.
> 
> I've wondered before about saying "OK, RDF 2.0 isn't binary, but
> n-ary.". Which would be weird for many people who someone see binary
> relationships as being the absolute core of the RDF project. So why
> isn't RDF n-ary? My take is because this would be pretty hard to do
> with all the messy open-world-ism of Web data.

Nah, no problem there. It would drive a truck through the 'graph' metaphor, is all. All those cute GUIs with lines and boxes would all be history. Back to nested parentheses, guys. 

> 
> If I remember right from Pat, CommonLogic deals with this by having
> every arity of a predicate be technically a different predicate.

No, CL does it much more simply. It simply ignores arty altogether: the whole idea is abandoned. Any relation can be written with any number of arguments (including zero). Semantically, a relation extension is simply a set of tuples (the ones it is true for) which can be any length, all jumbled together. BTW, the apparently insane zero case turns out to be incredibly useful and expressive.

> 
> So you might have an RDF-esque ''worksWith'/2, or maybe a
> 'worksWith'/5 where the extra slots are used for notions of 'from',
> 'to', 'role' etc. The problem there is what to do when they're
> missing. Is the simpler version implied by the richer version always?

CL answer is no. There are no built-in logical entailment between R with n arguments and R with m =/=n arguments. If you want those entailments, you write your own axioms to get them. thats the simplest way to write the semantics, and it has a kind of theoretical justification. Of course, this isnt quite fair if you don't have the ability to write axioms...

> 
> The TinkerPop annotated graph style I think does suggest a model in
> which all the decorations are explicitly subsidiary, and can 'drop
> off'; any graph with extras, when stripped of those extras, should
> still be true. And that's what would allow us to have different extras
> in different contexts and have the freeform mess still interoperate.

Hmm, that sounds tricky (but do-able) , but it would have some other consequences which might be unintuitive. Do you really *want* the larger story to entail the simpler one? In current RDF we don't say that :a :P :b . entails :a rdf:type :P (which is the analogous reduction from 2 to 1).

Pat

> 
> Not entirely convincing myself, but hopefully clarifying,
> 
> Dan
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Wednesday, 14 December 2011 21:34:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:46 GMT