Statute types. Suggest new field "Date of entry into force".

[JohnLukeBentley]

There already exists Date Enacted, the date when a bill becomes an act (at least in English common law jurisdictions?). But the Date of Entry into Force is a separate matter.

I don't know if legal bibliographic conventions use Date of Entry into Force. But it seems like a field of potential use.

[fbennett]

Legislation can go into force in increments, on multiple dates, and the list of effective dates expands as the original act is revised over time. I don't see how the complexities of the metadata can be handled within a reference manager.

[JohnLukeBentley]

Good of you to mention that ... yes there can be multiple dates in which various specified parts of the legislation come into force.

In principle, if one wanted to support an "... into force facility", perhaps there's two possible approaches:

• (More simply) have a Date of Full Entry into Force. That is, a field that is only to be filled when the entire legislation has entered into force (which might be a date on which the last sections of the legislation have come into force); or
• (More complexly) allow for multiple pairs of Date of Entry Into Force with Section(s) of Entry into Force.

Without suggesting implementing either proposition is trivial ... is there a scenario that couldn't be handled by the more complex proposition?

[fbennett]

A reference manager based on atomic items isn't a very good fit for expressing the full semantics of a statutory archive. Your former proposition is still ambiguous (i.e. when citing a consolidated act at a point in time after several revisions, is the "date on which the last sections of the legislation come into force" the latest in-force date, or that of the original legislation? Also, do sunset provisions ("this Act will expire in 20 years if not reapproved") count as in-force dates? With your latter proposition, even if the section assignments were perfectly clear in all cases, section numbers themselves move around,as when Congressional legislation is broken up and placed in various parts of the U.S. Code.

I don't think this is worth the candle.

[fbennett]

The Legal Information Institute at Cornell has an excellent series of posts on the workings of legislative process and the challenges that it poses for machine-readable identification systems.

[JohnLukeBentley]

I'm not sure pointing to the general complexity of handling legal metadata, as exemplified by the post you link to, is germane. Bibliographic metadata, legal or otherwise, gets complex. But this is what programs like Zotero and JurisM are built to handle. These programs handle the complexity so the user doesn't have to.

As a particular example handling jurisdictions in legal bibliographic metadata gets complex. But the infrastructure you've built, resulting in JurisM, substantially tames this complexity.

A reference manager based on atomic items isn't a very good fit for expressing the full semantics of a statutory archive.

I'm not quite sure what you mean by "atomic items". Perhaps you mean to warn against having fields that are strictly limited in the kinds of values they can contain. E.g. In Zotero and JurisM Date fields don't limit the values to a particular format. For example, in Date Decided you could put "My Birthday".

So if you mean that a field should except any text even if the field name suggests a particular value type (like a date, or a section number) ... then that could apply just as well to either of my propositions.

To go through your objections specific to my propositions:

Your former proposition is still ambiguous (i.e. when citing a consolidated act at a point in time after several revisions, is the "date on which the last sections of the legislation come into force" the latest in-force date, or that of the original legislation?

Whether a Statute item type in JurisM references legislation - as it looked at a particular point in time; or as consolidated (and current) - seems to be an ambiguity that exists independently of the issue of whether to introduce some kind of Date of Entry Into Force mechanism. Identifying point-in-time V consolidated legislation might be worth posting as it's own issue.

So introducing some kind of Date of Entry Into Force mechanism in the absence of identifying point-in-time V consolidated legislation handling doesn't seem to introduce an ambiguity that isn't already there.

Also, do sunset provisions ("this Act will expire in 20 years if not reapproved") count as in-force dates?

That could be handled either:

• By date ranges. E.g. 2018-03-29/2038-03-29
• Or with free test in the Extra field: "This act sunsets on 2038-03-29, if not reapproved"

With your latter proposition, even if the section assignments were perfectly clear in all cases, section numbers themselves move around,as when Congressional legislation is broken up and placed in various parts of the U.S. Code.

But as a user wouldn't you handle this by referencing the Congressional legislation (as it's own legislation) and/or that legislation as found in the US Code? That is, by creating separate JurisM entries?

So I'm not sure there's any in principle complexity that road blocks introducing a Date of Entry Into Force mechanism. However, it may well be that the need for capturing such information is so rare that it may not be worth the effort (consistent with your talk of candles).

I have no personal pressing need for it.

It does seem that the History field - or, as is useful as a last resort for any edge scenario, the Extra field - can be readily pressed into service by a user for Date of Entry Into Force information ... without having to make any changes to JurisM.