- From: Dave Reynolds <dave.e.reynolds@googlemail.com>
- Date: Thu, 14 Jan 2010 21:40:15 +0000
- To: Geoff Chappell <geoff@sover.net>
- CC: 'Pat Hayes' <phayes@ihmc.us>, 'Semantic Web' <semantic-web@w3.org>
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