- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 14 Jan 2010 21:17:23 -0600
- To: Geoff Chappell <geoff@sover.net>
- Cc: "'Dan Brickley'" <danbri@danbri.org>, "'Danny Ayers'" <danny.ayers@gmail.com>, "'Steve Harris'" <steve.harris@garlik.com>, "'Semantic Web'" <semantic-web@w3.org>
On Jan 14, 2010, at 3:12 PM, 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. > > 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. Well, fair enough. After all, RDF does already have what are in effect LISP S-expressions embeddable in it, so this is always *possible*. But I thought the idea of this thread was to find a way to avoid all this pseudo-Lisp list hacking using triples. <rant> This brings up a broader issue. Everyone agrees its good to keep RDF simple. But keeping RDF simple by making it in effect into a general- purpose construction kit, and then expecting that as a matter of routine people will use the constructions, isn't really being honest about 'simple'. OWL/RDF is a lot less simple than RDF itself largely because its written in what we might more honestly call OWL-syntax- coded-in-lists-described-using-RDF, which IMO isn't really RDF any more. If we want to expect RDF to do this kind of thing, then it ought to have a whole datastructuring facility built in explicitly, perhaps along JSON lines, rather than prostituting the triple store to be a data structuring tool. </rant> Pat > > Rgds, > > -Geoff > > > > > ------------------------------------------------------------ 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 Friday, 15 January 2010 03:18:28 UTC