[rdfweb-dev] Dating Service/Intro

Stephen Pollei stephen_pollei at comcast.net
Tue Jan 6 19:27:26 UTC 2004


On Tue, 2004-01-06 at 03:06, Danny Ayers wrote: 
> I don't think maturity of FOAF is really the issue - the core parts (Person,
> knows) are relatively stable, any changes will almost certainly be
> backwards-compatible.
> Regarding scope, the range currently covered by the FOAF namespace is IMHO
> probably about right, the additional characteristics would probably be best
> put in other namespaces.
> We already have one for relationships, physical
> things like hair colour (and Stephen's genes) could go in another, political
> (?) things like nationality etc in other etc.
Thats about where I think you are wrong. On what principle should for
instance gender, myersbriggs, img, mbox, depicts, dna_checksum, name,
interest, geekcode, near_by, and birthday be included and hair color be
excluded? Lets play name the Razor? They are all attributes that
generally humans have. These Attributes can be usefully divided by
whether they are primarily genotypic, randotypic, or behavioral.
The attributes themselves have degrees of permanence/stability,
apparentness, repeatability, inherentness, discriminatory/identifying
power, universalness etc.
You top used attribute mbox, and mbox_sha1 has severe weaknesses that it
is leans more towards the behavioral/non-inherent, non-universal,
relatively non-permanent, and relatively non-descriptive of real world
attributes.
It is severely borken in that you treat it as a time immortal truth that
one email address is forever used by one and only one
entity/agent/person. Three trivial counter-examples of your assumptions.
1) me I've had several emails over the years 
stephen.pollei at pentagon-1dms14.army.mil spollei at tincan.org etc etc
http://www.forbesfield.com/old-guests.html lists my old(94-95ish)
pentagon one BTW.
2) hotmail reuse... Jennifer Anderson Smith registers
hotbabe666 at hotmail.com uses it for awhile then goes away. Several months
later Mary Lu Patterson registers hotbabe666 at hotmail.com . rinse lather
repeat for other places that can recycle addresses.
3) Married couple that uses James_and_Denise__Johnson at example.com
  I've seen that a few times.
So yes one can say that the razor is physical or real world can apply.
That causes problems though and contrast with gender and depicts(image)
which is much more physical. Gender; while there are cross-dressers and
transgender operations, it is usually stable. Gender and image are
usually apparent right off the bat when meeting someone in person.
People usually don't wear name badges with their email addresses on
them. I can repeat gender and image compare operations and get similar
results. Gender while can be changed is strongly genotypic with slight
randotypic component. img is also strongly genotypic witness identical
twins. Both are Universal; everyone gots a gender, and a face/body.Not
everyone has an email address, especially if you think historically.
gender has low entropy male/female covers 99% of the results. Baring
disguises and other abnormal conditions; given a photo of someone you
can pick them out in crowd afterwords usually.
The attributes foaf has now are weak and need some complementation.
Also please visit http://www.foaf-project.org/ it has the following
statement.
The Friend of a Friend (FOAF) project is about creating a Web of
machine-readable homepages *describing* *people*, the links between them
and the things they create and do.
Do you believe or disbelieve that the foaf project has *describing*
*people* within it's expressed charter/purpose statement?
Is hair color a typical, near universal way of describing people?

I appreciate the desire for proper modularity in design, but you can
also push too far to the other side. Things like the geo namespace
having two things in it and people like Norman Walsh
http://www.tbray.org/ongoing/When/200x/2003/12/13/MegaXML having tons of
namespaces he has to use. Too small of namespaces can increase
complexity in the interfaces. Also namespaces are more a kin too
libraries than source code modules. Think using namespace std; in c++
gives you tons of stuff. That doesn't mean that it is written with one
big foo.h and one big foo.c ... I don't think that the convention that
one namespace means one schema file is always a good one.
I have already written a little about cleavage points, coupling,
cohesion and other issues. Size should be one issue but not even a
primary metric for deciding what does and doesn't go into a namespace.
I'll re-quote "I think that usage, correctness, cost, and ease of use
should determine cleavage points for the people using a namespace."
I should have added relative completeness/self-sufficient of the schema.
Most schemas should maybe require generic schemas to complement their
usecases/profiles like dc,dcterms, etc . think libc,glib,stdc++ .
Or if it is a true specialization of something or uses something that is
both complex and truely outside its primary domain to use another
namespace. Too tiny of namespaces drives up cost, decreases usability,
causes model correctness to suffer, and doesn't acknowledge common
usecases/profiles.
Personally I like foaf, but I think it has a few issues regarding
temporal issues, incomplete attributes, and a few other small structural
flaws. To solve some of the problems would require turning some things
that are now properties into classes, and thus depreciating lots of
stuff.

http://www.catb.org/~esr/writings/taoup/html/ch04s01.html talks about
sweet spot in module size... too small causes it's own probs.
> I think it's likely that there
> are existing vocabularies (DAML somewhere?) that cover this kind of thing,
> but it sounds like it would be useful to create FOAF-oriented equivalences,
> with a foaf:Person as the subject.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20040106/198d7abf/attachment-0001.pgp


More information about the foaf-dev mailing list