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

On Thu, Jan 14, 2010 at 9:19 PM, Pat Hayes <> wrote:
> On Jan 14, 2010, at 11:31 AM, Dan Brickley wrote:
>> I periodically wonder what an RDF without the binary restriction would
>> look like.
> My 2c suggestions, as answers to the questions.

Thanks. Glad to be airing this :)

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

(perhaps plus the extra contextual slot we're all using for
context/source/who-said-it and general packaging?)

>> 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 good to know. Is there enough Common Logic data out there yet
to get any deployment feedback on how this design is working in

I wonder how that interacts with the decentralised social situation we
have in the Web?

Say I put foaf:livesWith in the FOAF namespace. And I furnish it
generously with 2 arg, 3 arg and 4 arg versions. If you want to deploy
a 5 arg version, you'd either need to lobby the foaf-dev list to
persuade it to be added, or else define a pat:livesWith /5 and define
axioms linking it to the other flavours. Say you had some instance
data 3 arg and 5 arg versions of livesWith, we'd need to persuade
authors to use foaf:livesWith for the 3 arg version, and pat:livesWith
for the 5 arg. Or else make a rather more clever namespace
abbreviation mechanism than we currently enjoy...

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

Yup. In Dublin Core circles we often talk about "dumbing down" rules;
I guess similar ethic to TimBL's talk of 'partial understanding', ...
ie. a requirement that enriching the data with nice extras and fine
detail shouldn't render it incomprehensible to older consumers who are
only familiar with the core idiom. If we opened up RDF2 from binary to
n-ary, it would take some care to preserve these characteristics. We'd
need a way not only of writing the axioms, but of consumers finding
them and being able to handle them, ie. to figure out whether
pat:livesWith(r1,r2,r3,r4,r5) is telling us that
foaf:livesWith(r1,r2,r3,r4). In  RDF-classic you can get a reasonably
long way without much inference. I wouldn't want to sacrifice that

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

Yes, exactly this kind of dumbing down is needed imho.

But bnode-y and "missing isn't broken" issues make things quite
slippery. So far we have been talking about arguments indexed by
simple count. But often we might have some missing bits of
information; perhaps we don't know the <address>, or the
<maritalstatus>, or the <sourcedocument> or the <assertedBy> etc. Two
designs come to mind there. The crudest is to introduce a known null
value, eg.

1. we know they were married, but not where they lived...
liveswith(alice,bob, data:Null, married)

2. we know where they lived, and that they were married
liveswith(alice,bob, "52 Festive Road", married)

liveswith(alice,bob, "52 Festive Road", data:Null)

Now this is simple with a couple of args, but if we had a few more,
eg. '17 useful things to know about living with', coordinating gets
ugly. I get that feeling I get when I'm given access to somebody
else's organically grown, application-dependent SQL database:

liveswith(alice,bob, data:Null, in_sin, data:Null, thursday, 'F',
'CHECKED', 3, data:Null, bob, "Bob"(lang:en), data:Null, data:Null,
0231555252223, -1, rented, arrears, "backup-export.html", "EN-uk",
true )

There's a lot of structured data there. And we don't know a lot about
it. Or even really how to talk about it clearly.

What does the 20th argument of liveswith/20 mean? If I want to propose
a 22-arg version, and so does say Danny, and we agree on the meaning
of the 21st arg but differ in how we use the 22nd, ... how's that
going to be documented clearly and used reliably?

So a natural instinct at this point is to say, ... ok ok, let's name
the args. That way we don't have to count on our fingers all day. But
that doesn't completely help, since I could supply person1, person2,
moved-in-date, sin-status, source-doc and exception-day args to
livesWith/16, and you could supply the same but intended for
livesWith/18 (which has different semantics). We could invent more
syntax to keep track but I'd hate to be the one trying to teach
developers about it.

Besides, as we end up with these kinds of structures, with named
fields/arguments, it starts to look like RDF inside RDF. Would we name
the arguments with URIs? Could they be re-used across predicates? eg.
:source-document or :sin-state might be applicable in contexts other
than :livesWith, and in fact would need to be consistently
referenceable across the different flavours of :livesWith anyhow.

Where does this leave us? I don't know. I somewhat expected RIF to map
out this territory. Maybe they have and I missed it in the detail?

I think the underlying requirement here is to be able to talk about
packets of information larger than simple flat triples, and to not be
forced to invent fictional entities simply as an artifact of the need
to package such information together.

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

That kind of rule would say, 'whetever else you see attached to this
binary relation, you can throw away if you like and it'll be as true
as it ever was'. That could be a nice based to start from. I doubt
non-'extendable' properties would get very far in the public Web, but
there might be apps that could still use them.

Very much thinking out loud,


Received on Friday, 15 January 2010 09:56:55 UTC