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

On 15/01/2010 09:56, Dan Brickley wrote:

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

What do you mean by "map out this territory"?

RIF provides n-ary predicates (uniterms) as well as the "frames" which 
map to RDF.

It does also provide named-argument uniterms in the BLD dialect. Just as 
P(foo, bar) does not entail P(foo), each signature of names is distinct 
so that P(arg1->foo, arg2->bar) does not entail P(arg1->foo), though it 
does entail  P(arg2->bar, arg1->foo) i.e. order doesn't matter.

Named-argument uniterms are not included in Core since the aim of Core 
was to be minimalist and you can always implement named-argument 
uniterms using positional uniterms.

Dave

Received on Friday, 15 January 2010 10:32:30 UTC