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

On 15/01/2010 11:42, Dan Brickley wrote:
> 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...".

Upgrading RDF was never part of the RIF charter. Even just adequately 
supporting RDF was challenge enough :)

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

Personally I don't find this flavour of named-argument uniterms 
massively useful (because you still need to remember the entire argument 
list, there's no &rest) and they are just syntactic sugar.

> Are the args named with URIs, or in some way re-usable?

No, they are plain unicode strings and not re-usable. A named-argument 
uniterm just has a signature of "ArgNames". An argument name used in one 
predicate has no connection to the same name used in a different predicate.

After all, if you want to name the predicates and reuse them in other 
contexts then the obvious way to do that is use binary relations and you 
are back to RDF. Or in RIF's case "frames". So RIF has:

   s [p1->v1, p2->v2]

which maps to the RDF:

    s p1 v1; p2 v2 .

> Is it feasible
> to write rules or document patterns that convert / dumb-down amongst
> similar signatures?

Sure, with rules can you map between frames (thus RDF), n-ary predicates 
and named-argument predicates to your heart's content.

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

See [1] for the official list. I've no direct personal recommendations 
to offer.

Cheers,
Dave

[1] http://www.w3.org/2005/rules/wiki/Implementations

Received on Friday, 15 January 2010 14:04:57 UTC