- From: Sandro Hawke <sandro@w3.org>
- Date: Tue, 10 Apr 2001 12:44:20 -0500
- To: jos.deroo.jd@belgium.agfa.com, www-rdf-interest@w3.org
>> Issue 1: RDF M&S Does Not Provide Sets > >Just to make sure that we talk about the same thing, I understand a set >as defined in http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=set Yes, exactly. >> 5) ...? anything else? > >Well, we have been using recursive lists with predicate :list and object :nil >as you can find out at http://www.agfa.com/w3c/euler/lists.axiom.n3 I think you're using n3 curly-brace expressions to denote something interesting but beyond the scope of n3 as I understand it. Some kind of an operator structure, I think. My sense of n3 is that curly-brace expressions simply denote sets of RDF sentences. Can you turn the first line {:x :in {:x :list :b}} a log:Truth; log:forAll :b, :x. into English for me? Actually, let's use an instantiation: :foo :in {:foo :list :bar}. I read that as: ":foo" has an ":in" which is the mathematical set containing only the RDF sentence which has the subject ":foo", the predicate ":list", and the object ":bar". That hardly seems like what you meant. Pending understand that, I can imagine two more list construction mechanisms from your suggestions here: nil (the empty list) append (the three-way relation between a prefix list, a suffix element, and the resulting list) and list (the relation between an element and a singleton list containing just that element) concat (the three-way relation between a prefix list, a suffix list, and the resulting list) [this is an interesting construction in that it does NOT have a concept of the-empty-list.] They both have the problem of involving a three-way relation. In decomposing them into the binary relations we want, we end up with slightly different concepts. append(result, prefix, appended_element) turns into binary relations via argument-labeling: append_result(append_action, result) append_prefix(append_action, prefix) append_appended_element(append_action, appended_element) or if you're feeling adventerous via Currying: append(result, curry1) curry1(prefix, appended_element) both of which seem more clumsy than First/Rest. Is there some elegance here I'm missing? Ignore lists for the moment, I should certainly have added another "set" mechanism: element (the relation between a set and each of its elements) but that doesn't help us answer NOT-in questions unless we have some logic with negation to use with it. And I think we'd want a set structure mechanism to underly the logic mechanism. > [[[A difference list is a special kind of a list. Instead of being ended > by nil, a difference list has an uninstantiated tail so that new > elements can be appended to it in constant time. A difference list > is written as List - Tail where List is the beginning of the list > and Tail is its uninstantiated tail. Programs that use difference > lists are usually more efficient and always much less readable than > programs without them.]]] Ha ha ha. Very funny comment there. I don't see how they are different from list expressions involving variables -- a nice trick in systems design, but not a fundamental mechanism for defining what lists are. -- sandro
Received on Tuesday, 10 April 2001 12:44:27 UTC