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

The majority of this conversation went on when I was asleep, so I feel
like I missed the point where I can jump in. But I'm going to do so
anyway...

2010/1/15 Pat Hayes <phayes@ihmc.us>:
>
> On Jan 14, 2010, at 10:50 PM, Jiří Procházka wrote:
>
>> On 01/15/2010 04:17 AM, Pat Hayes wrote:
>>>
>>> On Jan 14, 2010, at 3:12 PM, Geoff Chappell wrote:
<snip/>
>>>> 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>
>>
>> Wasn't this the whole idea of RDF? Simple language for expressing any
>> information? Doesn't it use triples, simple relations between two
>> objects, specifically for the reason that it is universal, and any kind
>> of structure can be expressed by it?
>
> There are two notions of universal here, and we shouldn't get them confused.
> One is a universal programming language, which can be used to build
> arbitrary data structures and define operations over them. In other words,
> in fact, a programming language. The other sense is a universal
> *descriptive* language, which RDF is supposed to be , but isn't because it
> is too simple. (Thats why we need OWL, etc.; though RDF is closer than I
> used to think, see my ISWC talk.)
>
> My point was only that if RDF needs to *use* sequences (like, as data
> structures to encode OWL syntax, for example, or as a way of hacking N-ary
> relations using only binary links) then this is more like building data
> structures than describing anything, and maybe it would be better to admit
> this up front and deal with it with a real datatstructuring notation. It
> wasn't the whole idea of RDF to have it be a kind of awkward version of
> simplified LISP.


This really resonates with me. While it's possible to write the data
structure for anything in triples, it doesn't necessarily make it a
good idea.

Thinking of lists, these are fine from the perspective of data
structure, but they are a pain to query (and impossible without SPARQL
1.1 or some of the various SPARQL extensions out there), and hence
reason on. On the other hand, they *do* have the advantage of a
semantics, which puts them ahead of many other options for data
structures.

My other major pain is N-ary predicates. Sure, we have the W3C note on them:
  http://www.w3.org/TR/swbp-n-aryRelations/
However, this is more a discussion of the benefits of several
different approaches. It doesn't define a standard, and doesn't
provide any semantics. Personally, I'd be happy to see a standard
which told everyone to build n-ary predicates some particular way
(even if it's not ideal for a given scenario), and provided semantics
that everyone could rely on. This is, incidentally, what rdf:List
gives us today for lists.

Regards,
Paul Gearon

Received on Friday, 15 January 2010 21:20:10 UTC