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

On Fri, Jan 15, 2010 at 11:31 AM, Dave Reynolds
<dave.e.reynolds@googlemail.com> wrote:
> 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"?

I meant really, "be RDF 2.0", ie. upgrade the base language to address
these little annoyances. When people asked me whether RDF would always
be binary relations, I used to say things along lines of "hmm maybe
the RIF guys will make a proposal that'll provide the way forward
there, let's wait and see...".

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

Maybe the job's done then? :)

Are the args named with URIs, or in some way re-usable? Is it feasible
to write rules or document patterns that convert / dumb-down amongst
similar signatures?

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

Thanks for the summary! Can you recommend any (even partial)
implementation of BLD dialect for people to experiment with?

cheers,

Dan

Received on Friday, 15 January 2010 11:42:32 UTC