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

-----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. 

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. 

Rgds,

-Geoff

Received on Thursday, 14 January 2010 21:12:57 UTC