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

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