[rdfweb-dev] FOAFnet and the future of FOAF in commercial systems

Jeremy Gray jeremy at jeremygray.ca
Thu May 6 23:55:31 UTC 2004

> -----Original Message-----
> From: Danny Ayers [mailto:danny666 at virgilio.it] 
> Sent: Thursday, May 06, 2004 3:22 PM
> To: B.K. DeLong
> Cc: jeremy at jeremygray.ca; 'Marc Canter'; Leigh.Dodds at ingenta.com;
> Subject: Re: [rdfweb-dev] FOAFnet and the future of FOAF in commercial


> What specific actions would be the minimum change needed in practice to 
> achieve what you're asking?
> E.g.
> * changing the term_status property on foaf:name and foaf:knows to
> * drawing a line through the middle of the spec document with foaf:name 
> and foaf:knows above it labelled "Core", and everything below the line 
> marked "Modules"?

The five "broad categories" shown in tables in the spec probably wouldn't be
a bad place to start, but even there I see a few things that don't jive.
Some examples include (but are not limited to):

- numerous "unstable" and "testing" constructs that really should be into
"stable" by now (eg: Agent - if Person is "testing" (though it should be
stable), Agent bloody well better be at least as stable if not moreso)
- img and depiction/depicts can't really be in Basics when Image is over in
"Documents and Images", now can they? :)
- PPD likely deserves special status, given the need for it, whether
integrated into Core or put into a non-Core but highly prominent module
- title/family_name/givenname/firstName could probably do with being
refactored out into their own module where their modeling could be addressed
more fully by appropriate domain experts
- made/maker may or may not really belong in "Documents and Images", based
on coverage
- knows likely would need to be pulled into Core for any of this to be of
much use
- "Personal Info" could probably be broken up a bit as well


> danbri and libby are the maintainers of the spec, and personally I'm 
> more than happy to go with their judgement. But so far I don't think 
> they've been given anything to judge...

I too would be happy to defer to the maintainers, though I do appreciate the
opportunity to put in my two bits.

Jeremy Gray

More information about the foaf-dev mailing list