Re: Outcomes from Jan 2 telecon

Chris Welty wrote:

> Thanks for adding this, Dave.
> 
> Dave Reynolds wrote:
>> Then there was discussion on which, if any, of those three should go 
>> in the core. Gerd suggested that rather than have all three in the 
>> core we pick one based on use cases, I thought that received fairly 
>> broad agreement.
> 
> That wasn't my impression.  The core should, from a design perspective, 
> remain a core. The agreement I heard was that we should attempt to find 
> a way to translate between the different approaches. If they are 
> interchangeable, then it makes sense to pick one.

So if they are not interchangeable the core would have none of them?

>> [I was going to insert an appeal to the charter in here but the 
>> charter isn't helpful. It says:
>>
>>    """In order to allow interoperability with RDF and object-oriented 
>> systems, the syntax must support named arguments (also called "role" 
>> or "slot" names), allowing n-ary facts, rules, and queries to be 
>> provided through property/value interfaces."""
>>
>> Justifying slotted syntax based on RDF makes little sense to me but 
>> presumably would correspond to the relational semantics, whereas 
>> interoperability with object-oriented systems would presumably be 
>> better served by one of the other semantics.]
> 
> I don't know where that requirement came from, I found it odd when I 
> first read it, too, but note that RDF does NOT have a relational 
> semantics. I suspect that this requirement has to do with the fact that 
> in order to represent relational n-tuples in RDF you must either use 
> lists OR make a node that "represents the tuple" with (named) edges that 
> point to the elements (arguments) of the tuple.  The latter approach 
> corresponds to the idea of slotted/keyword syntax, and I assume this is 
> also what was meant by "object oriented systems" here - that an object 
> corresponds to an n-tuple with slot names corresponding to argument 
> positions.  Obviously using RDF Lists corresponds to a positional syntax.

Ah, that makes some sense, I hadn't been thinking in terms of 
representing relational n-tuples. I had simply been thinking of RDF 
"roles" as being binary relations.

> A disconnect between the relational view and this tuple-as-object view 
> is identity.  In the relational semantics, the same ordered tuple is a 
> single element, even if you try to repeat it.  In the tuple-as-object 
> view, two objects with the same arguments (ie all the same slot-value 
> pairs) are not necessarily the same. 

Sure. Though isn't this is a place where the RDF and object semantics 
diverge (which is one reason that paragraph in the charter seems so 
confusing)? In the RDF representation, assuming the node is a bNode, 
then the RDF graph containing two "copies" of the tuple and the RDF 
graph containing one copy simply-entail each other but there is no 
corresponding notion for objects. I realize this doesn't contradict what 
you said, just because the two graphs are equivalent doesn't imply 
identity of the tuples in the graph with duplicates.

> There is also a disconnect in the other direction, however, that has 
> been festering in my mind.  I think most of us who use RDF have been 
> thinking that RIF will treat RDF triples as ordered binary predicates, 
> e.g. the triple Chris brotherof darren would be brotherOf(Chris,Darren) 
> in RIF.  This requirement with its "compatibility with RDF" phrasing 
> seems to suggest that someone thinks there should be some special set of 
> RDF nodes that will be treated as tuples, so that brotherOf(Chris, 
> Darren) would actually be represented in RDF as something like:
> 
> A Arg1 Chris
> A Arg2 Darren
> A type brotherOf
> 
> Hmmmm...

Ugh, I certainly hope not.

Dave

Received on Wednesday, 3 January 2007 14:09:23 UTC