[rdfweb-dev] XSLTs for FOAF, Spring v1.3.1 and plans for FOAF spec improvements

[Ian Davis]

On Tuesday, 24 June 2003 at 14:27, Dan Brickley wrote:
> Re (ii), vocabulary stability and confusion, I have a plan(!). Rather than
> worry whether FOAF itself is 'stable' or not, I intend to tag each vocabulary 
> item with 'stable','unstable','testing'. For eg., 'foaf:homepage' is stable;
> 'foaf:surname' is unstable; much of the rest is 'testing'. More on this in due
> course. I hope this should clear up some concerns folk have w.r.t. deployability
> of different bits of FOAF vocab.
Is this a sign that the vocabulary is too broad? I've been musing over
some ideas about taking some OO principles and applying them to
vocabularies. There's one called "The Common Closure Principle" which
states (rather stuffily):

"The classes in a package should be closed together against the same
kinds of changes. A change that affects a closed package affects all
the classes in that package and no other package.".

What it means in practice is that you package your classes in groups
that change for the same reasons. The most obvious packaging
strategy most people use it to group by functionality, so in a
programming context, you might have 'reports' and 'payroll'
packages. However, if a new class of employee is added then you have
to change two packages and inform all the other entities that depend
on them. Applying the CCP you might split the packages up into
employee type packages each containing the relevant report and payroll
classes. You then add a new package when a new class of employee is
added and users of the existing packages don't need to be informed.

I'm wondering if the same sort of strategy can be applied to
vocabularies: repackage them so that different areas can change for
different reasons. e.g. In FOAF the identification parts (name, mbox)
are likely to change for different reasons than the relationships and
information (homepage) parts, so maybe thats how a split should be
made.

All, completely speculative of course, and very early in gestation.

I've just finished Robert C. Martin's Agile Software Development (ISBN
0135974445) which discusses all these principles in depth. He has some
sample chapters available
(http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles)
including one that tals about CCP explicitly:
http://www.objectmentor.com/resources/articles/granularity.pdf




- Ian <iand at internetalchemy.org>
"If we knew what it was we were doing, it would not be called research, would it?"