Re: Alternatives to containers/collections (was Re: Requirements for a possible "RDF 2.0")

Geoff Chappell wrote:
> -----Original Message-----
> From: semantic-web-request@w3.org [mailto:semantic-web-request@w3.org] On
> Behalf Of Pat Hayes
> Sent: Thursday, January 14, 2010 3:19 PM
> To: Dan Brickley
> Cc: Danny Ayers; Steve Harris; Semantic Web
> Subject: Re: Alternatives to containers/collections (was Re: Requirements
> for a possible "RDF 2.0")
> 
> 
> On Jan 14, 2010, at 11:31 AM, Dan Brickley wrote:
> 
>>> On Thu, Jan 14, 2010 at 4:20 PM, Pat Hayes <phayes@ihmc.us> wrote:
>>>> A lot, perhaps all, of this hair could be avoided if RDF allowed  
>>>> general
>>>> tuples as well as triples. All that is needed is some way to put N  
>>>> things
>>>> into a sequence: so, put N things into a sequence. The 'graph  
>>>> model' would
>>>> be a hyperlink, drawn as a polygon (eg triangle for N=3) rather  
>>>> than a line.
>>>> In triples-style syntax, it would just be moving a dot.
>>> I periodically wonder what an RDF without the binary restriction would
>>> look like.
> 
>> My 2c suggestions, as answers to the questions.
>>> Would each property/relation have a fixed arity, eg. dc:source might
>>> 'be a 4', 'foaf:knows' a 7?
> 
>> No. But it might be useful to distinguish 'really binary' ones, which  
>> only fit in triples, from the others, which can take any number of  
>> things in the sequence. Or maybe not, whatever. But the default should  
>> be, any number (even though most of them will be 2 in practice, ie  
>> triples.)
> 
>>> That doesn't make a lot of sense to me. So
>>> presumably they'd vary freely. In which case, we have a lot of
>>> figuring out to do when wondering whether   livesWith(alice, bob,
>>> 2007, 'y') implies livesWith(alice,bob) or livesWith(alice, bob, 'y',
>>> 'foo.html'). The binary straightjacket makes some of these questions
>>> impossible, albeit maddeningly...
> 
>> The Common Logic answer is very puritan: each number of arguments is a  
>> separate assertion, and they are all independent (unless you write  
>> axioms connecting them.) So liveswith(a b c) has nothing to do with  
>> liveswith(a b) or with liveswith(a b c d), etc., as far as the logic  
>> itself is concerned.  This is actually quite elegant and works well  
>> WHEN you can write the axioms you might need. So maybe we would need,  
>> for RDF, some way to attach some common inference patterns to these by  
>> giving properties to the property of the tuple. For example, one  
>> useful and common pattern allows ends of argument lists to be lopped  
>> off, so that
>>
>> liveswith(alice, bob, <address>, <maritalstatus>)
>> entails
>> liveswith(alice, bob)
>>
>> and we might specify this pattern (in a semantically extended RDF) by  
>> asserting
>>
>> liveswith rdf:type rdf:ExtendableProperty .
>>
>> But this is very much off the top of my head. Whaddayathink?
>>
>> Pat
> 
> I wonder how much of this needs to be in RDF itself vs. in query/rule
> languages that operate over RDF. 

Good point.

> E.g. we support rules in our sparql extensions and while we of course
> support rules with triples at the head, we also support ones that have n-ary
> relations at the head. I find the non-triple variety useful for of course
> dealing with inferring relations that have a natural arity greater than
> three but also for just performing transformations without polluting the
> triple space. Similarly, we have a native list type which is useful for
> things like accumulating values -- something that would be extremely ugly
> with a pure triple syntax. In both cases I find the extensions
> useful/necessary for processing RDF efficiently, but I never really feel the
> need to push the extensions into RDF storage/graph layer. 

Indeed RIF already has n-ary relations (with the same 
each-arity-is-distinct approach) and native lists. So those capabilities 
are there in the larger stack.

Dave

Received on Thursday, 14 January 2010 21:51:00 UTC