Lists Home |
Date Index |
- From: "Sean B. Palmer" <email@example.com>
- To: Dan Brickley <firstname.lastname@example.org>, Martin Bryan <email@example.com>
- Date: Fri, 29 Dec 2000 13:43:45 +0000
> We're in the business of making a cartoon characture of the
> world here, not representing it in full nitpicky detail.
The point is that there are some mailboxes that are owned by individuals,
and they should be able to be used to represent the individual that owns
them... that's the whole essence of the FOAF stuff, as well as my little
rant. But, if the owners change, or you have a dual owned mailbox or
whatever else, there is no reason that you can't have more RDF to describe
that. Thus, if a processor can work out that box1 and box2 are owned by the
same person, then you can use either box1 or box2 to reprsent that person
and that should cause any problems either.
> Point of all this being that we shouldn't conflate individuals with
> their various online representations and activities, but that we can
> nevertheless use properties of the latter to indirectly identify the
Yes! Although by using RDF we are really making first class assumptions
here...unless the properties themselves are ambiguous.
> (3) Fancy Semantic Web inference stuff ("don't hold your breath...")
> As above but drawing additional conclusions based on complex
> rules and re-application of (2).
> From where I'm standing, (1) seems really handy, (2) is critical to
> deploying this stuff in the grubby real world where things don't
> have URIs, and (3) is, er, something to keep an eye on.
The point of the original example was that this is such a simple
application of (2) that it opens the door for (3) [I hope!] I suggested as
such by pointing out that if the owner of a certain mailbox is male, then
it cannnot also be female. Not too hard to represent using ontology,
surely? You could use DAML to say that male is the inverse of female.
I've been toying about with all of this, and came up with the idea that if
we are associating a mailbox with a person, then it is going to have two
classes of data: name and info, i.e. the name of the person(s) associated
with the mailbox, and the information about that person. Therefore, I came
up with this:-
All of the "asserts:" bits are classes, and the "foaf:" and "me:" stuff are
properties. In this case, asserts:name means that this mailbox has one
owner, who may or may not posses other mailboxes. The cool thing is that we
*don't* have to associate asserts:info with asserts:name, because as
asserts:name is a property (term used loosely) of the mailbox, then the
asserts:info must also be about the same information. For example, if X has
a date of A and a title of B, you can say that the thing of title B has a
date A (if X is unique).
The next step is to start on the (admittedly simple) logic for "me:gender".
Anybody want to hack that up before I give it a go myself?
Sean B. Palmer
"Perhaps, but let's not get bogged down in semantics."
- Homer J. Simpson, BABF07.