[foaf-dev] Re: updated FOAF spec

[Dan Brickley]

+cc: Tom Baker

(your original didn't make it to the list, sorry; I could forward it, 
but am leaving all your words intact in this message, hope that is 
enough instead)

(I'm a bit wordy here; excuse me, I've been thinking about this stuff 
for too long...)

Ivan Herman wrote:
> Thanks a lot Dan, this is a good step.
> 
> I would suggest, when we all agree, to make a news item on a blog. I can
> do that (and will probably do) on my personal one, I wonder whether it
> would be appropriate to do it on the SW activity news, too (I did
> publish some 'external' news, with the approval of the CG, so you may
> want to raise it there).

I'm happy for it to be blogged, and will do so myself also. But I would 
be happier to push out an even better revision on a days-not-weeks 
schedule. The vast majority of the edits this time were of the "repair" 
variety, rather than progress. I think it should be possible to do much 
better, now that these basic fixes are in place.

> I am surprised that some of the terms are still not considered stable.

That was a conscious choice. For several reasons:


  * to avoid perfectionism; it was important to make some progress
  * to avoid suprises; to have the spec sit idle for months then leap 
everything to "stable" status seems somehow rude
  * because the term stability vocabulary is itself "unstable"; see my
   note to the W3C SWD WG at
   http://lists.w3.org/Archives/Public/public-swd-wg/2007May/0049.html

> Eg, foaf:knows is labelled as 'testing', though this is probably one of
> the most widely used property in foaf files... I am still not sure what
> the decision mechanism is to get that (for example) stable? 

I think the fundamental should be that stability is proposed (on the 
foaf-dev list, or elsewhere and reported here). And that no objections 
are raised, or that objections are at least discussed and noted.

Prior to this revision, the specification lacked any text associating 
expectations of future change with "stable"; we were radically unclear 
what exactly "stable" meant. Rather than make a huge philosophical and 
process debate of this, I think a "creeping professionalism" approach is 
appropriate. This is a new technology area, and nobody amongst us has a 
guaranteed right answer here: a lot of intuition (and yes, guesswork) is 
involved. By anology, when in the RDFCore WG we took on the task of 
updating RDF itself, I made some cautious edits to the document at
http://www.w3.org/1999/02/22-rdf-syntax-ns even though on some 
perspectives it was "stable" and "frozen" because associated with the 
1999 REC. Similarly with FOAF, I think we want some notion of stability 
that allows for tenative, cautious and respectful minor changes in the 
future. In the "Status of this Document" section I wrote:

	This revision of the specification consists mostly of editorial 	
	improvments. In addition the properties maker and made, as well
	as the clases Agent and Organization are now marked as "stable",
	in acknowledgement of their unproblematic usage in the Semantic
	Web community, and as an indicator that only minor changes to
	their document are anticipated for the future.

If that, and the other language in the status and evolution section 
meets the broad approval of this list, of users of FOAF and groups such 
as POWDER, EARL, SIOC, DOAP who use FOAF terms, then I would be very 
happy to go ahead and progress more terms to "stable". As part of this I 
would like to also use the SWD WG to document what we mean in this sense 
of "stable".

There are some aspects to RDF term stability where I think we can, as a 
community, make more progress. In the early days of FOAF, I could crawl 
the entire linked RDF Web and load all the world's FOAF data into 
Prolog. Those days are long gone. I keep a snapshot for nostalgic 
purposes, see http://rdfweb.org/people/danbri/rdfweb/allfactoids.P
...without the ability to have a global usage overview, understanding 
stability is hard. And therefore knowing what to declare stable, what to 
improve versus what to leave as-is, is also hard. I had some initial 
discussion with Tim Finin about using Swoogle stats to inform these 
judgements in the FOAF world, and I think in general this is something 
that will be increasingly important to those managing widely-deployed 
RDF vocabularies. And it is harder than simply "counting" usage, or 
looking for obvious inconsistencies. We need to estimate the deployment 
costs of change. For example, many many millions of FOAF triples derrive 
from a single Perl script in the LiveJournal codebase. A single change 
there would, in a matter of weeks, create massive change. Whereas any 
FOAF embedded in free-floating documents is almost impossible to change. 
And the modest but real support for consuming FOAF in the Safari browser 
that Apple ship with MacOSX is also "in theory" centrally changable, yet 
in practice we know it is defined over the XML/DOM representation, and 
also probably hard to get changed. Many factors such as this go into any 
measure of "is it worth changing / fixing", for any RDF vocabulary. 
Dublin Core is probably the classic example here.

These difficulties in assessing the cost of in-place change (rather than 
the different but related cost of new stuff in a new namespace) affect 
all RDF vocabs. Dublin Core and FOAF got big first, and hence felt that 
pain first, but I think we can learn from this (perhaps via the SWD WG) 
and figure out some tricks for understanding those costs better. To my 
mind, having better data from RDF crawlers would be a huge plus. I'd by 
much more willing to declare --- for example --- foaf:geekcode to be an
owl:DeprecatedProperty, perhaps move it to a "foafplus" namespace, if 
there were persuasive evidence that it is essentially unused. The 
Swoogle-based report at 
http://ebiquity.umbc.edu/blogger/how-the-w3cs-geo-vocabulary-is-being-used/
is an example of where I think we could go here...

> (There are
> fairly large number of those...). I guess the goal would be to make them
> stable as soon as possible and not wait several years:-) The section on
> evolution that you put in does not say anything about that...

In any standards-related work, I prefer to make commitments about the 
nature of change, rather than its pace. Not only FOAF, but eg. DC, RDF, 
RSS1, XQuery, SPARQL ... ... everything takes longer than originally 
hoped. But I think in this case we can move again much more rapidly. 
When http://www.w3.org/Press/RDF was written, whoever would've thought 
that the rules language work would just be starting up, 10 years later? 
Or the PICS migration part? And we haven't yet got to the digitally 
signed RDF part yet.

But let's set a goal, and measure progress against it. By 1st August 
2007, I would like the only things in the FOAF spec marked "unstable" to 
be terms that are either new, or have documented open issues against 
them, recorded in the public wiki. I would like the only things marked 
"testing" to be terms whose stability we are assessing, against some 
refined notion of "stable" (hopefully refined with help of the SWD WG) 
and with real deployment data from one or more RDF crawler. Is this an 
approach that sounds plausible?

> I am not sure I understood your remark on embeddded RDF/XML. I looked at
> the source and did not see anything special. Can you explain?

The RDF/XML is towards the very end of the document, for no strong 
reason beyond idea that in a browser, the human-readable parts load 
first and display first, and that any display errors introduced by the 
non-XHTML RDF markup will be limited if they appear at the end of the doc.


> I know this is a lower priority but... the text explicitly refers to the
> www.foaf-project.org site but, if so, that site should be updated, too.
> I just played with it and:
> 
> - I tested foaf-a-matic from Firefox with some semi-phony data and it
> did not work. I could go through all the steps and it simply did not
> return any data.
> - the 'activism' page still has some notes to editors
> - the 'news' goes to 404
> - among people it still refers to Libby's (non existent) page on ilrt
> 
> etc. I do not know whether this page is still important to have (there
> has been many things done since setting up this); if yes, it should be
> updated, if not, we should probably remove the reference from the foaf
> spec...

It was tempting (too tempting) to try to fix that at the same time. I 
switched over from the previous minimal single-page FOAF site last year 
without the time to follow through on the fixes needed; that was clearly 
a mistake. The next rev to the FOAF spec will be accompanied by a first 
set of fixes to the site, as well as (more importantly) some sysadmin 
work on the Dreamhost box to allow others to help manage it.


> Overall, it is a great step forward. Any (even practical) help that I
> can offer to move ahead?

Thanks. I think first on the list, would be to help sketch some 
definitions for "stable", "unstable", "testing" for deployed RDF 
vocabularies, ie. help write down an account of the kinds of changes 
that might be considered acceptable in an otherwise stable vocabulary 
(and its documentation). Second would be to help find some people with 
RDF crawlers and lots of real-world data, and figure out ways in which 
those efforts can help inform the ongoing development of the vocabs used 
in that data. Third, ... to have a monthly (say...) FOAF status catchup 
on the SemWeb Coordination Group call, so we can record progress (and 
lack thereof) somewhere beyond foaf-dev. How's that sound?

cheers,

Dan

> Ivan
> 
> P.S. A mini-remark:
> 
> Code in FOAF Auto-discovery: something went wrong with formatting on
> Firefox/Windows, the line goes over two lines and the code overlap (did
> you use tabs instead of spaces?)

Not sure I see what you see, but in a narrow window in macosx firefox it 
does look odd too. The problem is probably something to do with having
switched on justification in CSS: Will investigate.

ps. I have added the list of addresses cc:'d here to foaf-dev's mailman
"list of non-member addresses whose postings should be automatically 
accepted."; am happy to add more if non-members want to be able to post.