From: Dan Connolly (connolly@w3.org)
Date: 10/11/00
pat hayes wrote:
>
> In DAML-ONT:
>
> </Property> <Property ID="disjointUnionOf">
> <label>disjointUnionOf</label>
> <domain resource="#Class"/>
> <range resource="#List"/>
> <comment>
>
> for unionOf(X, Y) read: X is the disjoint union of the classes in
> the list Y: (a) for any c1 and c2 in Y, disjointWith(c1, c2),
> and (b) i.e. if something is in any of the classes in Y, it's
> in X, and vice versa.
>
> cf OIL disjoint-covered
> </comment> </Property> <Property ID="intersectionOf">
>
> <! COMMENT: This isnt the usual notion of 'disjoint-union'. The usual one is the union of two disjoint copies of the arguments. Imagine replacing A and B by A' and B' where A' differs from A in having all the elements of its intersection with B marked as 'first copy', and similarly for B' but marked 'second copy', then the disjoint union of A and B is the union of A' and B'. So for example the disjoint union of a set with itself is a set with two copies of everything in the original set. >
Two copies? in a set? I don't understand.
As to the "usual" notion of disjoint union,
lemme try google... Ah... now I see what you're talking
about...
http://mathworld.wolfram.com/DisjointUnion.html
But that's the 2nd hit nominated by google. The 1st
one is consistent with what I was talking about:
For example, if T represents
the type of triangles, R the type of rectangles and
C the type of circles, then we can say that an
object is a triangle or a rectangle or a circle by
saying that it belongs to the type T or R or C. In Nuprl
this type is written T|R|C.
In general if A and B are types, then so is their
disjoint union, A|B. Semantically, not only is the
union disjoint, but given an element of A|B, it must be
possible to decide which component it is in.
Semantically, not only is the union disjoint, but given
an element of A|B, it must be possible to decide which
component it is in.
http://www.cs.cornell.edu/Info/Projects/NuPrl/book/node39.html
But perhaps something like "partitionedBy" would be less
ambiguous?
I don't really know what's the common idiom here;
I added this at the request of somebody else.
> <! QUESTION: what is the value of your disjoint-union when the classes arent disjoint?>
er... the same as the "value" of any other false assertion,
such as 5<4.
> </Property> <Property ID="complementOf">
> <comment>
> for complementOf(X, Y) read: X is the complement of Y; if something is in Y,
> then it's not in X, and vice versa. cf OIL NOT</comment>
> <! COMMENT: It might be safer to use relative complement,
Probably so...
> ie subtraction of one class from another. Then complement is relative complement from the universal class. The reason this might be safer is that for many people there is no universal class, so (absolute) complement isnot exactly well-defined. In any case relative complement is often handy in its own right. >
> <Property ID="oneOf">
> <comment>for oneOf(C, L) read everything in C is one of the things in L;
> This lets us define classes by enumerating the members.
> </comment>
> <! QUESTION: Does this mean that C and L have exactly the same members? >
Yes, though the relation used to relate a member
to a class it belongs to (rdf:type, whose
inverse is often called instance-of) is different
from the relation used to relate a member to a list
(item).
And it makes sense to speak of the nth member
of a list, but not the nth member of a class.
(You could talk about nth w.r.t. some order
relation...)
> <Property ID="imports">
> <label>imports</label>
> <comment>for imports(X, Y) read: X imports Y; i.e. X asserts the* contents of Y by reference; i.e. if imports(X, Y) and you believe X and Y says something, then you should believe it. Note: "the contents" is, in the general case, an il-formed definite description. Different interactions with a resource may expose contents that vary with time, data format, preferred language, requestor credentials, etc. So for "the contents", read "any contents".
> </comment> </Property>
>
> <! COMMENT: I'm sure you know this is a can of worms,and I won't ask about 'content', but what (kind of thing) is X supposed to be here? (A class??) >
X and Y are documents; things that (syntactically) contain
(syntactically) statements. Or... to be even more
precise: they're resources that respond to request messages
with reply messages that contain documents that
contain statements.
It's sort of a long story, but
I think it's a story that I can specify in detail
(unlike things like absolute complement, where
I pretty much have to wave my hands.)
I just told the story to somebody else in www-rdf-logic;
see if that explanation works for you...
Assertion by reference [was: Comments on Annotated DAML...]
Dan Connolly (Wed, Oct 11 2000)
http://lists.w3.org/Archives/Public/www-rdf-logic/2000Oct/0005.html
Briefly, the following axiom specifies daml:imports:
if
answer(q1, a1)
subject(q1, r1)
says(a1, [imports(r1, r2)])
answer(q2, a2)
subject(q2, r2)
says(a2, s)
then
entails(a1, s)
(I might be able to strengthen the axiom
by changing says to entails in the
two premises, but I'm not sure just yet...
it could be that both imports-literally,
where the says form of the premises is used,
and imports-logically, where the entails
form of the premises are used, will both
be useful.)
> In DAML-NUM
>
> <Class ID="Numeral"> <label>Numeral</label> <comment>a sequence of digits (perhaps a sign? decimal place?). Radix 10, I guess. Note that "10" is a numeral, but the corresponding number is something else: "10" is a label for that number; i.e. daml:label(n, "10"). @@hmm... is label unambiguous over Numbers? or do we allow, e.g. "010" and "10" to denote the same number?
> <! I'd suggest allowing leading zeros, but they don't change the denotation. But note, people often do want to distinguish 10 from 10.0 as being different kinds of thing, so be careful, if you allow decimals, to let people keep integers and reals separate. Similarly for signs and negative numbers. Usual class distinctions for mathematicians are: naturals (positive only)/integers/rationals/reals; for geeks are: integers/reals. Naturals are natural for counting things. >
Programmer geeks often mean "floating point number"
when they say "real" too. There be dragons.
Floating-point datatypes are not real datatypes
Mark Reinhold <mr@eng.sun.com>
5 October 1999
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JanMar/0130.html
Anyway... daml-num is even less baked
than the rest of this stuff... but I think the thing
to do for now is to make a Natural class and an
Integer class and let anybody who needs more
than that make their case.
> <Property ID="min"> <domain resource="http://www.w3.org/2000/08/daml-ont#Class"/> <range resource="#Integer"/> <comment>for min(S, x) read: x is the minimum of s; i.e. x is in S and every y in S is not less than x
> <! Might be better to phrase this as every y in S is greater or equal. The way you have it, S could contain some non-integers and still have a minimum. Similarly for max.>
Oops. Good point.
> <Class ID="Range"> <label>Range</label> <comment> a set (class) of integers ranging from some min to some max. @@Hmm... how to say that each instance of Range is a subclass of Integer?
> <! You could say that the range was the powerset of Integer, ie set of all subsets of Integer, maybe? Powerset (powerclass?) is likely to be generally useful.>
Yeah, that seems reasonable.
> <! Why not have this a function from a pair of integers to a class?>
The basic building block is a 2-place predicate p(x,y); if you
know something about it, you can regard it as a one-place
predicate p(x)=y, but there's no syntax for f(x,y)=z.
There are various ways to make up the difference,
sort of like f(<x,y>)=z. i.e.
first(pair, x)
second(pair, y)
range(pair, xToy)
That's basically what all that restrictedBy/Restriction
stuff is for. We could use that approach here, but
it didn't occur to me at the time.
> >From DAML-EX
>
> <Class ID="Person"> <subClassOf resource="#Animal"/> <restrictedBy> <Restriction> <onProperty resource="#parent"/> <toClass resource="#Person"/> </Restriction> </restrictedBy> </Class>
> <! Well, this isnt wrong exactly, but its also not a very good definition since it is a nonterminating recusion. Does this matter in this framework?>
I don't think it matters; in particular, because this
isn't intended to be a definition. Just some claims
about the thing called Person: that it's a Class,
that it's a subclass of #Animal, and so on.
> <UniqueProperty ID="mother"> <subProperty resource="#parent"/> <range resource="#Woman"/> </UniqueProperty>
> <! Is father a UniqueProperty also,
Yes... UniqueProperty says the same thing as
cardinality=1.
(*every* reviewer notices this. I should
add a comment in daml-ex and daml-walthru
so I won't have to keep explaining it ;-)
> or are you making some biological point here?>
no.
> <! Does it follow from the above that father and mother between them constitute all the parents? How would that conclusion be derived in DAML?>
Umm... if, by "the above" you mean the stuff above
there in daml-ex, including the cardinality=2 statement
about parent, then yes, I guess it follows
that father an mother are all the parents.
I don't have any particular set of inference rules
in mind, but to sketch the argument, if I know
father(Pete, Bob)
and
mother(Pete, Mary)
then I can infer from the ranges of father and mother that
type(Bob, Man)
and
type(Mary, Woman)
and from the disjointness of Man and Woman, I can
conclude that Bob and Mary are distinct. Then,
from the premise that father
and mother are subproperties of parent, I have
parent(Pete, Bob)
and
parent(Pete, Mary)
and finally, since the cardinality of parent
is two, and Bob and Mary are distinct, I
know I've got all the parents.
>
> <TransitiveProperty ID="ancestor"> <comment>@@need a property to relate this to parent</comment>
> <! This is actually quite tricky. What you want to say is that ancestor is the transitive closure of parent, which means that 1. a parent is an ancestor, 2. that ancestor is transitive, and 3. that ancestor is the smallest (least true) property satisfying 1. and 2. This last part is the trickiest part and is hard to state properly even in full first-order logic. It might be a good idea to actually have transitiveClosure in the language as a primitive if you really think it is going to be used a lot, rather than try to define it.>
Er... right... transitiveClosure is "a property
to relate this to parent."
as to being tricky to specify... I find the
definition in the larch shared handbook
http://www.sds.lcs.mit.edu/Larch/handbook/RelationOps.html
fairly straightforward (after I puzzled over it a bit).
I wonder if there's some
built-in property of larch that hides the trickiness/
> <Class ID="Car"> <comment>no car is a person</comment> <subClassOf> <Class> <complementOf resource="#Person"/>
> <That seems to say that a car is *anything* that is not a person.
really? how so?
> What you should say is that it is a subclass of the complementOf,
That's what it does say, no?
> or just say they are disjoint.
Yes, that would probably be more straightforward.
> Or you can say the relativecomplement is unchanged. >
unchanged? Hmm... maybe I see what you're saying...
Person \ Car = Person.
> <Class ID="Height"> <oneOf parseType="daml:collection"> <Height ID="short"/> <Height ID="medium"/> <Height ID="tall"/> </oneOf> </Class>
> <! I guess it is churlish to point out that this is meaningless, since a tall man is shorter than short building?>
Yes, churlish indeed. ;-)
It would be in order, however, for you to suggest
a better example for oneOf.
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
tel:+1-913-491-0501 (office phone as of 27 Apr 2000)
mailto:connolly.pager@w3.org?subject=pls%20call%20+1-NNN-NNN-NNNN
This archive was generated by hypermail 2.1.4 : 03/26/02 EST