Bill Status Data Model : Terminology Post #2

[sean.m...@gmail.com]

All,

In the first post on Terminology we looked at the word "bill" in some
detail to establish terminology that reflects the complexities of how
that word is interpreted. I suggested "measure" as a noun we could use
in the all encompassing sense to cover bills/acts/resolutions/
executive redirection orders etc. (All of which exist in at least some
US Legislatures with differing meanings.)

Gary Schaefer suggested "Instrument" as another possible catch-all
term. I like "instrument" because of its existing status as
established legal terminology (http://en.wikipedia.org/wiki/
Legal_instrument) and also because "measure" has a meaning in
typesetting that can sometimes cause confusion over in the statutes/
session law publications department :-)

Also, in recent posts and in some personal conversations, there is a
preference for a pragmatic, simple mapping approach. Something we can
start with and evolve over time as we gain momentum...So lets move on
to the next bit of the modeling.

We now know that we are going to model instruments. The first question
that raises is this: do we model instruments plural or instruments
singular? This might sound like splitting hairs but it is actually
very important. If we model a collection of instruments then our model
must be at least two levels deep. I.e. in XML it would be something
like this:

<instruments>
<instrument>...</instrument>
...
<instrument>...</instrument>
</instruments>

This nesting caused by the creation of a collection is best avoided in
the early stages of modeling in my experience as it causes us to think
about aggregation when we should really be focusing on the meat of the
model which is the instrument-s themselves. If we get the instrument
model correct, then collections, queries, filter expressions etc. will
look after themselves. So, lets concentrate on the instrument element
itself.

The second question is: what attributes do we associate with each
instrument? I propose we spend a while discussing this one before we
get into the "how' part. Take something like "long title" for example.
Let us figure out if we want a "Long title" before we worry about
whether it is a fixed width string or an enumerated type or an
attribute or a sub-element etc.

To get the conversation started, here are some possible attributes
that I think we could start with:

name: English description

identifier: Code used to identify the measure in a short and
(somewhat unique) form e.g. HB1234

sponsors: Entities that introduced the instrument into the formal
legislative process

Comments? I'd suggest we list all possibly interesting attributes at
this point but then concentrate on the smallest set that folks think
would work. I.e. what is the smallest amount of info that an
instrument would need to convey to make it truly useful? What we are
seeking here is a happy overlap between "truly useful" and "truly
applicable to all legislatures"

Does anybody out there have an example of an instrument in their
legislature for which name, identifier and sponsors would not be
mappable?

Regards,
Sean

[Blake Courtney]

I would suggest we draw the elements directly from NIEM core and reuse
not reinvent.

A bill would be a document. You can apply an DocumentAugmentation to
it that is domain specific.

I have included a ZIP file of the subset, and a wantlist to use in the
NIEM tool.

Thanks,
Blake

[Karen Suhaka]

I like "instrument".

I think good additional parameters would be some kind of date, the relevant governmental body (federal, state, etc), and (I know I know) status.

As far as plural or singular, I must defer to those more in the know.  That said, I'd leave singular.

Cheers,

Karen

[Sean McGrath]

Hi Blake,

Thanks for contributing!

There will certainly be elements from NIEM core that we can reuse (I
have a list I created a while back. Some from NIEM core, some from
justice domain...) but that is a little later down the road for us.

I suggest at this stage, staying away from syntactic and (most)
structural concerns until we get a handle on the model at a purely
logical level (i.e. not much more than entities and attributes for now).

Also, I don't want us to get tied into NIEM's approach to customization
and derivation too early. For one thing, I want to make sure that we
ensure we can have a pure REST/JSON as well as a NIEM-XML way of doing
bill status.

As regards bills being documents...., there is a whole lot more to it
than that, as will become apparent as we go through this modelling
process...:-) When it comes to considering bills themselves in their
various manifestations, we will likely use an FRBR-based model
(http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records).
I want to make sure that whatever work we do here can be applied with
that level of rigour to help states meet their (growing) requirements
under things like the Uniform Law Commissions's model law for authentic
legal materials (http://bit.ly/uKAyQ7).

Although bill status (our current focus) is generally not considered a
legal (or even para-legal) output of a legislature it is, in my
experience, a mission critical output. Many legislators and lobby groups
rely on it. So, even if its not strictly speaking a requirement, I'd
love to treat bill status will full-on statute-book levels of rigour.

Also, when it comes to the text of individual manifestations of
bills...the bill text per se will not be part of bill status. We will,
when it comes to it, need to xref to manifestations of bill texts from
bill status. That will bring up all aspects of the FRBR model, the need
for permanency in the URIs, URLs versus URNs, point-in-time referencing
etc. etc. :-) Another days work.

Also, Grant Vergotinni's work on SLIM will be relevant here for bill
text manifestations. See http://legixinfo.wordpress.com/. I haven't
talked to Grant about SLIM (hi Grant!) but I would hope that we can
dove-tail our effort here (bill *status*) with Grant's work (bill text)
and find a way to ensure that both work together.

Also, we have Sunlight's 50-state API to consider. We want to make it
easy for Sunlight developers to consume our feeds - and avoid the need
for scrapers. See
http://sunlightlabs.com/blog/2009/50-state-project-momentum/.

These three efforts are very much inter-related of course but they are
different animals. A common theme I have seen in legislatures is the
on-going struggle to ensure that bill status information and the
manifestations of bills at points in time (e.g. PDF docs) are in synch
with each other. The sync point is the data that generally appears in
both outputs i.e. information related to sponsors is typically both part
of bill status and part of the bill text itself. However, bill sponsor
information can - and often does - change as the bill goes through the
workflow...

Regards,
Sean

[Shay Wilson]

      I really like the terminology instrument.  It avoids the tangling of local terminology by using a more general encompassing term.  A couple notes from my side.  Just saying date isn't helpful, I have 5 dates associated with a bill date Introduced, Last Status date, Next Scheduled Date, Passed House, and Passed Senate.   I going to guess when a date was suggested someone meant the Introduced date or the Last Status date, but it's unclear. 

     I'm unsure how other legislatures versioning works, but I would recommend the version (title or number) as part of the attributes.  I also have a lot of questions on how to properly pass back a sponsor, but I'm sure that will be discussed more fully at a later point. 

[Sean McGrath]

On 11/23/2011 03:57 PM, Shay Wilson wrote:
> Just saying date isn't helpful, I have 5 dates associated with a bill
> date Introduced, Last Status date, Next Scheduled Date, Passed House,
> and Passed Senate. I going to guess when a date was suggested
> someone meant the Introduced date or the Last Status date, but it's
> unclear.

Ok. Thanks. I will add these to the list of possible attributes.

> I'm unsure how other legislatures versioning works, but I would
> recommend the version (title or number) as part of the attributes.

Ok. Noted.

> I also have a lot of questions on how to properly pass back a
> sponsor, but I'm sure that will be discussed more fully at a later point.

Yes, indeed it will :-)

Regards,
Sean

[Shay Wilson]

     I certainly not suggesting we add all those dates,  I was merely stating that we should say "Date" and think that it means the same thing to everyone.  I think Gary brings up a good point that actions should be added as an attribute list like sponsors, but then we will need to define what actions look like.  (Which we should do later so as not to get bogged down at this point).

[sean.m...@gmail.com]

Shay,

Yes. Understood. I think the relationship between bill "state" and
bill "history" is at the heart of this. Every event in the history of
a bill is a candidate for a date/time attribute. Date introduced,
referred to committee, sent back to chamber of origin, etc. etc. A
possible model that is forming in my head is one in which the
instrument itself has very few directly attached attributes : possibly
just the identifier for the instrument itself e.g. "SB7". Then,
everything else that is associated with the instrument is a date/time-
stamped event. I.e

Instrument: ID = SB7
Event: Date/Time = YYYYMMDDHHMM. Name = "Introduced".
Event: Date/Time = YYYYMMDDHHMM. Name = "SponsorInfoUpdate".
...

That could give us a nice clean way of allowing everything about the
instrument to change over time except for its ID. I.e. titles can
change, sponsor info can change etc.

We could then perhaps model the common event of introducing an
instrument as a series of one or more Events that have the same date/
time stamp. I.e. if the bill is introduced, sponsors updated and long
title assigned all at 12:00 on 7th Jan 2011 we can infer the three
events all happened as part of a single Chamber/Committee action.

That would also cleanly deal with the case where instruments get
created at one time but have their sponsors/titles etc. set at a later
time.

In some legislatures I know of, certain instrument identifiers are
created and "reserved" for use later in the session.

Thoughts?

Regards,
Sean

On Dec 6, 4:40 pm, Shay Wilson <shay.wil...@gmail.com> wrote:
>      I certainly not suggesting we add all those dates,  I was merely
> stating that we should say "Date" and think that it means the same thing to
> everyone.  I think Gary brings up a good point that actions should be added
> as an attribute list like sponsors, but then we will need to define what
> actions look like.  (Which we should do later so as not to get bogged down
> at this point).
>

[Sean McGrath]

Forwarded for Gary Schaefer from Louisiana Legislature who is having some bounce problems with the list.

---------- Forwarded message ----------
From: Schaefer, Gary <scha...@legis.la.gov>
Date: Thu, Dec 8, 2011 at 1:49 PM
Subject: RE: {NIEM EDemocracy} Bill Status Data Model : Terminology Post #2
To: "sean.m...@gmail.com" <sean.m...@gmail.com>
Sean,

I like the idea of instrument "state" and instrument "history."  In Louisiana we refer to the "state" as the "current status date."  I agree with your other examples and analysis below except for the part where you say multiple things change in one step. [I.e. if the bill is introduced, sponsors updated and long title assigned all at 12:00 on 7th Jan 2011 we can infer the three events all happened as part of a single Chamber/Committee action.]  Something like this could happen in LA; it might be a single action, 2 actions, or 3 actions all with the same date.

 

Gary K. Schaefer

Senate Information Systems Coordinator

P.O. Box 94183

Baton Rouge, LA 70804

(225) 342-1001

(225) 342-9736 FAX

scha...@legis.la.gov

CONFIDENTIALITY NOTICE--This e-mail message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

 

-----Original Message-----

From: niem-ed...@googlegroups.com [mailto:niem-ed...@googlegroups.com] On Behalf Of sean.m...@propylon.com

Sent: Thursday, December 08, 2011 12:03 PM

To: NIEM EDemocracy

Subject: Re: {NIEM EDemocracy} Bill Status Data Model : Terminology Post #2

[Warren Smith]

On Fri, Dec 9, 2011 at 10:39 AM, Sean McGrath <sean.m...@gmail.com> wrote:
> Forwarded for Gary Schaefer from Louisiana Legislature who is having some
> bounce problems with the list.
>
> ---------- Forwarded message ----------
> From: Schaefer, Gary <scha...@legis.la.gov>
> Date: Thu, Dec 8, 2011 at 1:49 PM
>

> I like the idea of instrument "state" and instrument "history."  In
> Louisiana we refer to the "state" as the "current status date."  I agree
> with your other examples and analysis below except for the part where you
> say multiple things change in one step. [I.e. if the bill is introduced,
> sponsors updated and long title assigned all at 12:00 on 7th Jan 2011 we can
> infer the three events all happened as part of a single Chamber/Committee
> action.]  Something like this could happen in LA; it might be a single
> action, 2 actions, or 3 actions all with the same date.
>
>

I've been wanting to reply to this for a while. Please pardon the latency.

IMHO, it would be preferable to make the association between events
explicit (linked by some identifier) rather than implicit (occurred on
the same date).

In thinking about how that could happen, It occurred to me that there
could actually be 2 types of things that happen when an action is
taken by the legislature:

- A higher-level event occurs (concept in the legislative process domain).
- Some lower-level events occur as part of, or as a result of, the
higher-level event (concepts in the legislative system domain).

Such a system could be modeled so that a unique identifier for the
higher-level event is stored in the lower-level events, thus linking
them explicitly.

Such a system could be made more flexible by giving each unique event
an optional "parent event" identifier. This would allow a hierarchy
of event levels that was arbitrarily deep.

Just my $.02

--
Warren Smith

[Shay Wilson]

It may just be,  but I'm totally confused about what you just said.   Can you give an example from your experience because I've become lost in the abstract.