FOAFCommunityProcess
From FOAF
The FOAF 'Community Process' :)
Ths isn't a formal W3C-style standards process. But we should try to write some things down. There is some commonality between FOAF and opensource developer things like the Python Enhancement Proposal process. The Semantic Web architecture makes FOAF extension a somewhat more decentralised affair than that required for a language such as Python. --danbri
irc logs from FoafGalway (FoafGalwayBreakoutSessions).
Contents |
[edit] What we need
A recognition of the energy and intelligence people have invested in FOAF-related Semantic Web applications.
A lightweight, rough consensus effort to produce a useful, interesting and reasonably well documented set of RDF namespace documents to support real live Semantic Web vapourware. A few principles for contributing to collaborative RDF vocabulary design.
[edit] Notes
The focal point for managing the FOAF vocabulary (and related vocabularies such as WOT) is the rdfweb-dev list, augmented by this Wiki and by irc chat.
If you've got bright ideas, send them to the list, link them from the Wiki, discuss them in IRC.
If you've running code, sample data, test cases, schema/ontology definitions, that's even better.
If you persuade DanBri or LibbyMiller to add them to the FOAF namespace, great. If not, you can always create your own and life goes on.
Regarding ownership etc., the FOAF foaf namespace document is (c) DanBri and LibbyMiller (and published under a liberal Creative Commons license); we also manage its evolution based on community discussion, and run the rdfweb.org and www-foaf-project.org and related web sites. As a technology FOAF is highly dependent on W3C's open RDF and XML standards, which are unencumbered and royalty free. The FOAF spec just provides some vocabulary definitions for use in an RDF/XML environment. --danbri
[edit] Discussion at FOAF Galway 2004
See irc logs
We talked about this document, which was updated for that purpose.
Practical things...
* agreed that a regular 'heartbeat' for status/progress updates to FOAF spec (issue lists, TODOs etc) would be helpful. * agreed an initial IRC meeting 1700pm BST 2004-09-15 in #foaf, for status/update from editor; danbri to circulate a meeting agenda to rdfweb-dev. * discussed setting up foaf-talk@foaf-project.org and foaf-spec@foaf-project.org and RSS feeds, for easier tracking * talked about helping FOAF-like efforts thru W3C
[edit] Things To Aspire To
FOAFProcess Notes
Standards for standards-based vocabulary development
* Dublin Core and FOAF experience argue in favour of developing a process for a 'live', edited, vocabulary namespace whose contents and documentation evolve over time within a commonly understood approach. * Changes should be documented, motivated, and announced (by email, by RSS feed); dissent from changes should be (self-)documented and findable from the spec (eg. via Wiki). * Different kinds of change should be distinguished. New terms (ie. properties and classes) versus alterations to the definitions of existing terms. * Some changes make older documents false (eg. adding an rdfs:domain claim); others (eg. removing an rdfs:domain claim) merely remove formal justification for inferences that could previously have been drawn and circulated by users of the FOAF namespace. Both are serious, in that documents which had previously used FOAF namespace in good faith will change in their meaning (ie. truth conditions) based on an edit to the core spec. And software, which relied on certain patterns of meaning in the spec may need revision. * Purely textual changes to definitions can also alter the meaning of the documents that rely on those definitions. Distinguishing changes for clarity from changes in meaning is difficult but important to attempt. * The scale from 'unstable' through 'testing' to 'stable' is used to associate broad maturity levels with the definitions of the terms that constitute FOAF. They apply to the combination of the term's RDFS/OWL definitions, accompanying hypertext documentation, and to the term's deployed status in the wider Web. * An important aspect of being considered 'stable' is for the maturity of a term definition to be grounded in independent datasets, applications and running code (preferably published and open-source). * Changes to 'unstable' terms are expected and natural; changes to 'testing' terms are at the editor's discretion, are not to be undertaken lightly, and are generally a result of deployment/design feedback or a broader re-organisation undertaken for consistency purposes. * Since the meaning of FOAF terms is grounded in deployed practice (apps, code) and in natural language (prose definitions), a critical aspect of maturity is understanding their international and cross-cultural applicability. To this end, translations of FOAF term definition into non-English languages is encouraged, both to ensure careful review of definitions and to help identify accidental ambiguities or unarticulated assumptions. * Discussion and debate is improved by having a clear decision record / trail. While public email and IRC logs are critical, a higher level overview is also needed. The IssueTracker (wiki page) attempts this, but the prior debate surrounding a term or theme should also be easily findable from the FOAF specification. * Examples (test cases) are very useful for bringing focus and clarity to implementor discussions, and should be made available (somehow...) from the FOAF development web site. * a half-page scoping statement is needed, to understand the editorial assumptions that inform decisions about the evolution of the FOAF namespace. This should include goals (e.g. "roundtripping through vcard / vCard superset") and broad guidlines (eg. modelling assumptions / idioms adopted, and broader aspects of the design that apply to the entire namespace). * The process surrounding FOAF should have mechanisms for propagating requirements (eg. for new RDF vocabulary, or for associated technology such as RDF query, API etc) to relevant standards bodies, in particular to the W3C and to the Dublin Core Metadata Initiative. Liaison to these bodies (however informal) should be documented (eg. via SemWeb Interest Group of W3C) since newcomers to FOAF may not know the people and histories that link these communities. * These guidelines should be refined through practice, and tested through application to other namespaces / vocabularies. * Practical and logistic aspects of namespace management should be documented and their responsible treatment documented. These include the long-term purchase of associated domain names (and plans for their stability, eg. leaving in wills etc)., offsite backups, plans for fallback and recovery after server failure, PGP keys associated with the namespace editor, etc. * there should be some regular schedule / expectations surrounding spec evolution. This need not guarantee dates for features, but should at least have regular process reports and IRC or similar meetings to allow progress to be monitored, documented and understood by non-insiders. * earlier versions of the spec+namespace RDF should be archived, be available by datestamped URI, and clearly documented with versioning and status info. These frozen snapshots are for documentation and history rather than use as RDF namespaces (although this might be worth investigating).
