Recent posts

[Sean McGrath]

All,

I would like to take a moment to comment on recent posts (something I promised to do some time back!).

1 : Tom Bruce : (See Tom's full post here) http://bit.ly/t3QuMM

[SMG]
>> Fact 3) Links on legislative websites are also - by and large -

>> brittle. Links break.

[TB]
> Yeah.  This is just bad identifier design, or more accurately, a
> problem that stems from not yet adapting legacy identifier designs to
> the new environment that arises from exposure to the Web.

Indeed, the problem is primarily one of adaption to the world of the Web but
there are also significant challenges caused by the lack of unambiguous
identifiers for critical concepts such as committees. Bills can have long
names but also have short ones :-) Committees can have very long names
and the short ones - if they exist - are colloquial i.e. "SAG" for
"Senate Agriculture Committee".

Bill numbers help but they generally reset at session/biennium boundaries.
The problem with these is two-fold. Obviously the links may break but arguably
worse, the link might *work* but bring you to the wrong bill.

[TB]
>> Some work is needed to tie existing identifiers to Web-capable identifier schemes
>> (it's unlikely that the old identifiers will be legislated out of
>> existence overnight, and many have useful semantics that won't survive
>> Web exposure but are worth retaining).

Agreed. In KLISS (http:://www.kslegislature.org), we have created PURLs
(permanent URLs) for the main information objects:

    bills
    committees
    members

The URIs include biennium information. At the end of the next legislative
session an archive of the entire biennium will be created and all URIs
will be re-directed to the archive material in the Kansas Historical Society.

In order to do that, we had to - as you say - invent new identifiers.   

[TB]
>> Fact 6) Figuring out a standard representation for Bill Status is hard

> Yes.  There's a question here as to whether you want to build one
> standard, or an abstract interchange standard that is not as fully
> expressive or head-compatible as purpose-built approaches done by
> individual legislatures.  I tend to favor the latter -- a standard
> intended for interchange, plus each legislature kinda doing its own
> thing, with an eye to best practices.

Yes. I think an interchange-focused model makes a lot of sense, given
the diversity.

[TB]
>> You will probably  never get buy-in on a standard, at least not across-the-board in a
>> normal lifetime.

Getting these things adopted sure is hard but I think we can greatly
improve our changes by making sure we stay focused on interchange
and focused on keeping it simple.

[SMG]
> > Note also that I am concentrating on Bill Status here - as opposed to

> > Bill History and Bill Status codes. I.e. for now, I'm looking at a
> > model for capturing the state of a bill at one point in time as
> > opposed to looked at the set of actions (history) that have
> > accumulated on a bill. 

[TB]

> Right, although something that provides points of contact between a
> process/workflow model and a set of document models would probably
> enable the construction of history more or less automagically.

Yes it would but given the diversity of the workflows, it is probably best
if we provide some guidance as to how to do the mapping but
not attempt to model (or meta-model) the workflow.

[SMG]
> > Approach 3) Partial Vertical Mapping Model

> > Variation on (1) but with only a subset of a state's bill status model
> > mapped to the interchange model. It might for example, have
> > "introduced", "in commitee", "for final ction", "sent to governor" but
> > leave out more granular workflow states like "third reading in the
> > house of origin" or "committee of the whole - opposite chamber" etc.

[TB]

>Right.  For me this has a kind of inevitability.  There are certain
>"legislative events" in the document lifecycle that are going to be
>fairly universal, and others that while interesting to some kinds of
>audience are not worth pursuing even within one legislature -- I am
>thinking, in particular, of all the fine-grained shoving and hauling
>that goes on around procedural rules and so on, and would need
>extensibility into finer granularity anyway.

Yes. The interesting question I think is what are the events that
are "fairly universal"? I think we need to plan for a very small
number and hope it gets bigger over time. Also, I think we can do
a lot by having an open-ended coding scheme for statuses with
suggested forms of language rather than a statically-typed
"pick list". The latter would be lovely but given the diversity
is probably unrealistic.

[TB]
>>a) The target might more pragmatically be imagined as a core
>>interchange standard, plus a series of data-modeling "playbooks" aimed
>>at specific techniques for improving local practices and making them
>>more Web-of-Data-friendly; those local models would extend the core,
>>principally toward greater granularity.  This partakes of the
>>limited-horizontal approach to modeling of documents and other things,
>>like people, and a limited-vertical approach to modeling legislative
>>process.
Very useful input, thanks.

Regards,
Sean