[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New proposed definition for $has$a
|
As promised in the thread below, I want to
withdraw the suggestion I made Monday that $has$a might no longer be necessary
as a metagraph predicate. Instead I want to offer a new definition consistent
with our new definition of $has. $has definition: +x/$has/+y
==> (+x/+y) ==> +x+y Proposed $has$a definition: +x/$has$a/+y
==> +x/+y/$$ In other words, +x/$has/+y is an assertion
of the existence of a new set identified by the new XDI RDF subject +x+y. By
contrast, +x/$has$a/+y is an assertion of the existence of a member of the set +x+y,
but does NOT assert the existence of the whole set, and does NOT create a new XDI
RDF subject identifying the set. So: +x/$has/+y ==> asserts
and identifies a new set +x+y +x/$has$a/+y ==> asserts
(but does not identify) a member of the set +x+y This is consistent with English usage of
the words. For example: Drummond
has cats. ==> identifies
a new set: “Drummond’s cats” (which may be empty) Drummond
has a cat. ==> asserts
a member of the set of Drummond’s cats For the sack of precision, I also propose
the following inference rules: RULE XDI
RDF STATEMENT INFERENCE ====== ================= ========= Rule #1: +x/$has/+y infers
ONLY +x+y, NOT +x/+y/$$ Rule #2: +x/$has$a/+y infers
ONLY +x/+y/$$, NOT +x+y Rule #3: +x/+y/+z infers
ONLY +x/$has$a/+y, NOT +x/$has/+y Rule #4: +x/+y same
as Rule #3 Rule #5: (+x/+y) infers
ONLY +x/$has/+y, NOT +x/$has$a/+y What this does is cleanly separate the
semantics of $has and $has$a. $has always refers to a set, $has$a always refers
to a member of a set. This even follows in natural language English. For
example, I can say: A
car has tires. Now I can talk about the set “car
tires”. But that doesn’t mean that a particular car has tires –
they might be missing. Another example in the opposite direction is that I can
say: A
car has a watermelon. But that doesn’t mean I can talk about
“car watermelons”, i.e. it doesn’t mean there exists such a
general set, or that I can say: A
car has watermelons. Keeping these inference rules crytal clear
allows us to be very precise in XDI dictionary statements about when we are
creating a new set (class) – by using a $has statement – and when
we are creating a new set member (individual) – by using a $has$a statement. ********************* Lastly, if +x/$has$a/+y ==> +x/+y/$$, what
is the cardinality of $$? a)
zero or more b)
one or more I think it must be zero or more because there
are many times when you need to refer to a member of a set which may be empty.
Classic example: +person/$has$a/+middle+name. Some do, some don’t. All food for tomorrow’s telecon. =Drummond From: Drummond Reed
[mailto:drummond.reed@cordance.net] Markus, Thanks for researching this – it is
VERY useful info. I too did a search in several places for $has$a usages, but I
forgot to look at versioning. The other place we have been using both $has
and $has$a is in dictionary defintions. And there it is clearly useful. In
thinking about it more since posting that message on Monday, I’ve come up
with several other places where not having $has$a would actually be a problem. The good news is that I think there is a
corresponding definition for $has$a which works nicely with the new definition
of $has, and which would yield exactly the uses for $has$a that we’ve
found useful in versioning and dictionaries, but which would not introduce the
RDF problem we had before. I don’t have time to write it up right now,
but I’ll post something before tomorrow’s telecon, so we can go
over it on the call. =Drummond From:
markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello Hi, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]