- From: Dave Reynolds <dave.e.reynolds@googlemail.com>
- Date: Fri, 15 Jan 2010 10:31:38 +0000
- To: Dan Brickley <danbri@danbri.org>
- CC: Pat Hayes <phayes@ihmc.us>, Semantic Web <semantic-web@w3.org>
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