[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: thoughts on PATTERNS and FORMAT OF THE STANDARD
Andy Thanks very much for these views. I’ll certainly play them into the discussions on Thursday and I’m sure Peter will reflect on them as well. As you intimate we are potentially breaking new ground that may or may not work for us. That’s a difficult decision to make so perhaps we need to see some actual examples from Peter so we can touch and feel them which will help us decide. BTW good to have you back. John From: Andy Hopkirk [mailto:andy.hopkirk@gmail.com] John, by all means share these thoughts around if you feel they have merit for the agenda of the next TC call which I won't be able to attend, or for other purposes... PATTERNS I'll first confess a certain liking for patterns and - tongue in cheek - their complements the anti-patterns. Unfortunately it feels like I see more of the latter than the former in practice... Peter proposes a proof of concept to test the application of patterns principles to the TGF scenario. This is interesting... If the TGF scenario indeed proves amenable to this approach, it would be a significant outcome to go all the way and see the process through to completion. But I guess I have to question how many will see the merit in this form of output? How many will understand how to use the resultant pattern language properly? It's a real dilemma: we don't want to turn people off with the unfamiliar. It feels very appropriate, if you have previously 'got' what patterns are about; but that's the tricky bit with the world of patterns, few 'get it' and even fewer 'get it and use it'. Our objective is a standard that is tractable: it must be clear what is expected and you can get your head around it all at once or in parts, as suits your purpose. If we make it that TGF standard users require prior knowledge of patterns to appreciate what is presented to them, then (a) that prior requirement will need to be flagged up to them at the outset and (b) it risks limiting eventual adoption more than it facilitates however 'better' it is for those who understand why it is that way? On the other hand, yet more and more layers of documents with narratives and diagrams of varying layers of detail will only get us so far in completely describing what we mean by the TGF... Maybe it is better to utilise a variety of tools from the kit bag to make a more useful object of the TGF and to require a certain minimum level of knowledge before 'letting people loose with it'? I think it is worth exploring (a) whether patterns extraction actually works for the TGF (which is all that Peter is asking for at the moment) in order to (b) give concrete evidence for a subsequent Y/N decision on yet further work to completion and (c) to scope how much work that will actually be. As a bonus – and here I go off into things I don’t really know a lot about – there may be some first mover advantages to be had here? Yes, patterns can be stepping stones to algorithms can be stepping stones to machine processing; so, consider what is the likely future role and value of machine processing ‘stuff’ in the TGF domain? It might actually be considerable, e.g. there's a lot of EU money going into semantic web and related processing for e-policy and e-governance purposes. Connection with StratML… To the extent that the TGF is a ‘strategy’, ‘Yes’; but, is it just a strategy? Hmmm… need to ruminate on that one. Gut feeling is that TGF is more than a strategy. FORMAT OF THE STANDARD I've looked at the primer text and extracted its structure out into Excel so I could play with it outside the primer document... The parts that are fundamentally 'the standard' are, it seems to me at the moment, the compliance criteria. Peter has gathered these together in one section of the document (I found some minor inconsistencies when doing that)... If that section was developed into being a very short and straight forward definition of the TGF standard, then the Primer and other documents/ patterns we might make serve to explain the meanings of the terms used in the standard. For example, the standard would say...
and just as a reference would be provided to define the meaning of 'SHOULD' and 'MUST' elsewhere, so the same construction can be used to provide definintions of the meanings of 'Franchise Marletplace Model' and 'Policy Product Map'. By such means the text of the standard is kept short but precise, and that feels like the right way to go to make it more tractable to more people. Hope this is useful, Andy |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]