[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalcitem] GitHub etc.(long post...sorry)
Thanks, Chet, and thanks to everyone for the feedback.
It looks like we're in good shape. The LRR went through some cosmetic
changes during the holiday. The site is still here:
http://fbennett.github.io/legal-resource-registry/
The content will grow as contributors send in lists of courts, using
the spreadsheet forms hosted on the site. There are draft lists under
the yellow-highlighted bubbles on the top page, derived from content
at http://www.lexadin.nl/wlg/courts/nofr/courts.htm. I've written to
the maintainer of that site about the LRR remix, and the only response
has been a "Follow" in LinkedIn. In any case, these are just facts,
and will not be merged into the identifier system until they are
separately confirmed by contributors. I'll add a note to the site to
the effect that contributions are CC0 (public domain), but as far as I
am aware, lists of things are not subject to copyright. I don't see
how there could be a problem, but that's the genesis of the material.
Tying this work back into the MLZ reference manager has driven home
the importance of having a shared pool of uniform court identifiers.
You can't really build a general system for managing court judgments
until that is in place. I've also learned something about the
structure of identifiers, which might be worth stirring into the
LegalCiteM spec.
As an example, here is the current LRR identifier for the Southern
District of Iowa:
us;federal;district;ia.sd;bankruptcy.court
It turns out that, at the implementation level, it is important that
the final element names the court itself, and that the preceding
elements name the "geographic" scope (scare-quotes because arbitration
panels have a scope determined by private contract). Cleanly dividing
the two allows them to be independently suppressed when generating
printed citations. So here, "bankruptcy.court" can map to "Bankruptcy
Court" (or its abbreviation), "us;federal;district;ia.sd" can map to
"S.D. Iowa", and "us" can map to "U.S."
This *roughly* resembles the scheme set forth in the urn:lex IETF
draft "A Uniform Resource Name (URN) Namespace for Sources of Law
(LEX)." Within the draft, the preceding, "geographic" elements would
constitute a single element (period-delimited), separated from the
court name by a single semicolon. That could be done here as well -
but I'm not sure how necessary or desirable it is to conform to that
syntax. The url:lex draft is tied to a separate maintenance process,
and the more closely the LRR identifiers resemble the urn:lex
structures, the greater will be the likelihood of confusion.
That's all for now. Sorry that I missed the meetings today - we're
wrapping up academic term this month, and it's pretty busy here.
Frank
On Thu, Jan 8, 2015 at 2:12 AM, Chet Ensign <chet.ensign@oasis-open.org> wrote:
> Frank, Monica, Brian et al -
>
> Apologies for not getting back to you all on this sooner. Here is some
> feedback for you all to consider.
>
> First, we recognize that TCs have needs like what you are trying to
> accomplish and we are working on ideas to be able to support it. I hope to
> be able to share more with you in the near future.
>
> Next, Monica raises the key point for you to keep in mind: "From my
> knowledge it is fundamental to use those tools for achieving the correct
> standardisation process, for transparency approach, for managing the IPR
> issues properly and also for creating persistent URIs ofthe material that
> will be mentioned later in the standardization process. Otherwise we can
> have some problems in official steps." -- Simply put, content that you want
> to incorporate into TC work products, presumably culminating in OASIS
> Standards must be properly contributed to the TC and must be stored, made
> available and developed on the OASIS supplied platforms if you are to have
> the benefits and coverage of the OASIS TC Process and IPR policies.
>
> Having said that, we recognize that there are limitations to the OASIS tools
> and that a TC may wish to benefit from the work from other sources. In such
> a circumstance, the *key* action for the TC is that any such work be
> properly contributed (again, Monica pointed out how LegalDoc and LegalRule
> have accomplished this) and then incorporated into working draft. When work
> is properly contributed to the TC, the TC is free to incorporate the work
> into its deliverables. The important element of contributed work is that
> there be no limits to the Contributor's ability to make such grants,
> acknowledgments, or agreements with respect to the contribution as are
> required by OASIS policy. In other words, the person making the contribution
> has all the rights necessary to do so.
>
> What does this mean with respect to the github you are discussing so that
> "...we in the OASIS SC can use as a resource for our work"? It means first
> of all that, yes, you should keep it completely separate from OASIS and the
> TC. I.e. it is not an official TC resource, not sanctioned by OASIS, not
> covered by OASIS rules, etc. It would be alright to say something like "you
> may also be interested in the work of the OASIS Legal Citation Markup
> Technical Committee at..." or something like that but otherwise keep it
> completely separate.
>
> Second, it means that *if* you want to be able to incorporate any of the
> work being done there into the TC work product, anything contributed into
> the github must be done in a way that allows for its unimpeded copying and
> reuse outside the github. Work donated to the github must be done under a
> license that gives unrestricted rights to its reuse, by the SC or by anyone
> else. What you absolutely want to avoid is taking something from the github,
> incorporating it into the TC work product, reaching OASIS Standard and
> *then* having the original author come back and say "Oh by the way..." And
> yes - while rare, OASIS has had some instances of after-the-fact awkwardness
> caused by alledged improper contributions.
>
> The absolute safest way for something from a non-TC/OASIS person to be
> contributed to the TC is for the author to send it to the
> legalcitem-comment@lists.oasis-open.org mailing list. That is the purpose of
> that list and why I am so adamant about its use. That channel is currently
> the only mechanism we have for ensuring that anything you receive from
> outside the TC is defensible under our IPR policy. If you see something in
> the github that you want to incorporate into the TC work product, contact
> the author and tell them how neat and cool it is and how you'd like to use
> it and ask if they would send a copy to the -comment@ mailing list.
>
> Alternatively, if you are certain that the work being donated to the github
> has been done under a permissive license that allows for free and
> unrestricted reuse, then in theory a TC member could take a copy from the
> github and contribute it to the TC via the Kavi document archive or the TC
> mailing list. You are, however, taking on the risk should an objection later
> be raised.
>
> An alternative approach might be to refer to the github from your spec. For
> example, if the github contained citation patterns for different
> jurisdictions, you could make a normative reference to it and say in the
> spec "patterns that can be used for jurisdictions can be found here..." The
> potential downside there is that you make your spec depend in part on a
> resource outside OASIS that can't be guaranteed.
>
> I hope this is helpful in giving you some perspective on the work. My intent
> isn't to discourage you because I agree completely that Frank is doing great
> and valuable work here. My intent rather is to make sure you understand the
> implications for the eventual OASIS Standard so that you can proceed safely.
>
> Please let me know if you have any questions on this. I can invite Jamie
> Clark to discuss this with us further if you have more questions.
>
> Best regards & Happy New Year!
>
> /chet
>
>
>
> On Thu, Nov 20, 2014 at 8:11 AM, monica.palmirani
> <monica.palmirani@unibo.it> wrote:
>>
>> Hi Frank,
>>
>> I sympathize with you! I know the problem because with Akoma Ntoso was the
>> same and with LegalRuleML (and RuleML interconnection) also.
>>
>> In Akoma Ntoso case: we (Fabio, me, and UN) put the work (schema,
>> documentation, slides, examples) inside of KAVI and SVN as member
>> contributions and so those material was automatically adopted as part of the
>> TC. In this case we adopted the internal contribution.
>>
>> In LegalRuleML case: a member of RuleML Community made a contribution via
>> external mailing list
>> (https://lists.oasis-open.org/archives/legalruleml-comment/) to the TC
>> claiming the paternity and the license.
>> In this case we adopted the external contribution.
>>
>> You can find the format for claiming the paternity here (annex B):
>> https://www.oasis-open.org/policies-guidelines/ipr
>>
>> So it is important that you have a skype call with Chet as soon as
>> possible also with the participation of the LegalCite chairs in order to
>> find a good solution.
>>
>> This is my suggestion coming from similar experience, in order to not
>> discover later that we have made a mistake or created a trouble for your
>> work.
>>
>> Yours,
>> Monica
>> Il 20/11/2014 13:46, Frank Bennett ha scritto:
>>>
>>>
>>>
>>> On Thursday, November 20, 2014, monica.palmirani
>>> <monica.palmirani@unibo.it <mailto:monica.palmirani@unibo.it>> wrote:
>>>
>>> LegalDocML and LegalRuleML (but also the other OASIS TCs) are using
>>> the OASIS tools for cooperating and for contributing in the TCs.
>>>
>>> >From my knowledge it is fundamental to use those tools for
>>> achieving the correct standardisation process, for transparency
>>> approach, for managing the IPR issues properly and also for creating
>>> persistent URIs ofthe material that will be mentioned later in the
>>> standardization process. Otherwise we can have some problems in
>>> official steps.
>>>
>>> https://www.oasis-open.org/__resources/tools
>>> <https://www.oasis-open.org/resources/tools>
>>>
>>> Chet could help in these cases. Any time that I had some doubts
>>> about contributions, tools, IPR issues I asked to Chet.
>>>
>>> In any case we are using (in LegalDocML and LegalRuleML) the
>>> following tools:
>>>
>>> - Wiki - https://wiki.oasis-open.org/ (public)
>>>
>>> - JIRA - for managing the activities/task/ticket/bugs (not public
>>> only for the OASIS members)
>>> https://issues.oasis-open.org/__secure/Dashboard.jspa
>>> <https://issues.oasis-open.org/secure/Dashboard.jspa>
>>>
>>> - SVN repo - for including all the schema, documents, etc.
>>> https://tools.oasis-open.org/__version-control/browse/wsvn/?__sc=1
>>> <https://tools.oasis-open.org/version-control/browse/wsvn/?sc=1>
>>> (public)
>>>
>>> - KAVI - for the official documents approved by the TC. It is
>>> important to archive the official documents because we need links in
>>> KAVI for each official documents involved in the standardization
>>> process (minutes, working document, CSD). See this document for the
>>> naming convention of the files:
>>>
>>> http://docs.oasis-open.org/__specGuidelines/ndr/__namingDirectives.html#tracks
>>>
>>> <http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#tracks>
>>>
>>> Each document archived in KAVI is public:
>>>
>>> https://www.oasis-open.org/__committees/documents.php?wg___abbrev=legaldocml
>>>
>>> <https://www.oasis-open.org/committees/documents.php?wg_abbrev=legaldocml>
>>>
>>> https://www.oasis-open.org/__committees/documents.php?wg___abbrev=legalruleml
>>>
>>> <https://www.oasis-open.org/committees/documents.php?wg_abbrev=legalruleml>
>>>
>>> Each email in the mailing list and the attachment are public:
>>> https://lists.oasis-open.org/__archives/legaldocml/
>>> <https://lists.oasis-open.org/archives/legaldocml/>
>>>
>>> For the public accessibility to the resources/contributions see:
>>>
>>> http://docs.oasis-open.org/__specGuidelines/ndr/__namingDirectives.html#__accessibleURIs
>>>
>>>
>>> <http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#accessibleURIs>
>>>
>>> My 2 cents,
>>> Monica
>>>
>>>
>>> The problem (at least in the case of the courts SC) is one of manpower.
>>> The technical SC decided that controlled lists were preferable to dumb
>>> strings, for values with a finite scope. There are a lot of courts, and
>>> there are a lot of reporters, and there are many more intersections of
>>> the two. To build out the two lists and the relations between them is
>>> beyond the capacity of the committee membership, but there is a
>>> community that can help. Since both the community and OASIS have the
>>> same aim, I don't see any harm in activating the former, to produce
>>> material that can be vetted and adopted by the latter.
>>>
>>> Certainly OASIS groups have adopted external work in the past; the only
>>> novelty here is perhaps that the external product was conceived after
>>> the group formed.
>>>
>>> Anyway, we'll see how it goes - I'll try to talk to Chet sometime soon,
>>> to iron out any wrinkles.
>>>
>>> Frank
>>>
>>>
>>>
>>> Il 19/11/2014 23:09, Frank Bennett ha scritto:
>>>
>>> On Thu, Nov 20, 2014 at 6:40 AM, John Quentin Heywood
>>> <heywood@wcl.american.edu> wrote:
>>>
>>> Hi Folks,
>>>
>>> Couple of things:
>>>
>>> 1. The GitHub repository was discussed in the main TC
>>> meeting this morning,
>>> as was other off-site tools such as GoogleDocs. Ken pointed
>>> us to the OASIS
>>> Technical Committee (TC) Process document at
>>>
>>> https://www.oasis-open.org/__policies-guidelines/tc-process
>>>
>>> <https://www.oasis-open.org/policies-guidelines/tc-process>
>>>
>>> particularly Section 2.8 on TC Visability, which says:
>>>
>>> The official copies of all resources of the TC and its
>>> associated
>>> Subcommittees, including web pages, documents, email lists
>>> and any other
>>> records of discussions, must be located only on facilities
>>> designated by
>>> OASIS. TCs and SCs may not conduct official business or
>>> technical
>>> discussions, store documents, or host web pages on servers
>>> or systems not
>>> designated by OASIS. All web pages, documents, ballot
>>> results and email
>>> archives of all TCs and SCs shall be publicly visible.
>>>
>>> Both GitHub and GoogleDocs would seem to be in conflict with
>>> this, although
>>> as it was pointed out in the call, at least GitHub is an
>>> open standard,
>>> which can't be said about GoogleDocs. Many folks on the call
>>> were less than
>>> happy with the OASIS Wiki, which would seem to be the only
>>> official
>>> collaboration tool available. It was suggested that getting
>>> the work done
>>> was important, so perhaps we could use private tools such as
>>> GitHub as long
>>> as we put the official documents on the SC's public document
>>> repository,
>>> which would be here:
>>>
>>>
>>> https://www.oasis-open.org/__committees/documents.php?wg___abbrev=legalcitem-courts
>>>
>>>
>>> <https://www.oasis-open.org/committees/documents.php?wg_abbrev=legalcitem-courts>
>>>
>>> and conduct our technical discussions on this listserv. This
>>> seems
>>> reasonable to me.
>>>
>>> Now Frank has been doing some wonderful work on GitHub,
>>> merging the reporter
>>> data from CourtListener and the CSL project with what we
>>> have been doing and
>>> making it truly usable for us and other projects (like the
>>> Free Law
>>> Project). He thinks we should open the repository up so that
>>> others can
>>> collaborate. I agree, and I think this would dovetail nicely
>>> with the OASIS
>>> rules. If the work being done on the GitHub repository is no
>>> longer
>>> officially OASIS work, we don't have to worry about their
>>> rules. The GitHub
>>> repository becomes a tool for the whole free law community,
>>> that we in the
>>> OASIS SC can use as a resource for our work. We could rename
>>> it to something
>>> like the "Court Citation Project" or even something less
>>> lame than that. How
>>> do folks feel about this?
>>>
>>> For some examples of what Frank has done, look at:
>>>
>>> http://jqheywood.github.io/__CourtsSC/index.html
>>> <http://jqheywood.github.io/CourtsSC/index.html>
>>>
>>> and
>>>
>>> http://jqheywood.github.io/__CourtsSC/states.html
>>> <http://jqheywood.github.io/CourtsSC/states.html>
>>>
>>>
>>>
>>> Terrific!
>>>
>>> One question: Should I then remove the reference to OASIS from
>>> the
>>> header of the online docs?
>>>
>>> http://jqheywood.github.io/__CourtsSC/index.html
>>>
>>> <http://jqheywood.github.io/CourtsSC/index.html>
>>>
>>> That seems stingy, by it would indeed reduce the potential for
>>> people
>>> to take the work-in-progress as some sort of draft standard.
>>>
>>> If I read correctly, then, the repo itself can be made public?
>>> That
>>> would be great - there are already people out there ready to
>>> contribute to the effort.
>>>
>>> Some notes about infrastructure changes in the works chez
>>> CourtsSC ...
>>>
>>> For the CourtsSC docs, the next step will be to generate them
>>> directly
>>> from a filesystem data hierarchy of the content (which exists as
>>> of
>>> yesterday), with links on each court and reporter to their
>>> discrete
>>> source files in the GitHub filesystem. I think GitHub now
>>> automatically performs a fork and pull request when people
>>> without
>>> write permissions to an edit, so that will give us easy-access
>>> editing
>>> by outside contributors, and an editorial workflow for
>>> maintaining
>>> control over the end product.
>>>
>>> For extension and reorganization of the source files through the
>>> GitHub online UI, I'll add an explanation of how that works to a
>>> README displayed on every source page. So that will be covered as
>>> well.
>>>
>>> Finally, we'll need to work on validation and output. For that,
>>> we
>>> should have a discussion about what the constraints should be
>>> (beyond
>>> producing parseable source and valid XML). Then I can start
>>> mucking
>>> around with code.
>>>
>>> With validation in place, we'll be ready to tie the whole thing
>>> into TravisCI.
>>>
>>> https://travis-ci.org/
>>>
>>> Once on-the-fly validation is working, we'll be ready for
>>> scalable
>>> crowd-sourcing.
>>>
>>> I guess a final item will be the output. The current rendered
>>> view is
>>> handy for examining and working with the source structures, but
>>> machines will want something else. We should be able to generate
>>> it
>>> automatically, once we know what it is.
>>>
>>> Frank
>>>
>>>
>>> 2. In response to the discussion in our last SC meeting, and
>>> never being
>>> afraid to play the fool (or, if you ask my kids, BE the
>>> fool, but I
>>> digress), I asked the assembled TC what exactly a use case
>>> was, and what are
>>> we supposed to be producing. Everybody seemed happy that I
>>> had asked.
>>> Someone (I'm not sure who) described it thusly: HTML5 is the
>>> standard, a web
>>> page demonstrating all the different parts of HTML5 is the
>>> use case. John J.
>>> reminded us all that the SCs should not get lost in the
>>> weeds of detail, as
>>> he has seen other projects flounder because of it. We should
>>> be looking for
>>> the common things in these citations and writing them up. I
>>> think we may be
>>> close to ready for this in the US context very soon.
>>>
>>> Well, time to go home and make my eldest his birthday dinner
>>> (he turned 17
>>> today),
>>>
>>> John
>>>
>>> --
>>> John Quentin Heywood
>>> heywood@american.edu
>>>
>>>
>>>
>>> ------------------------------__------------------------------__---------
>>> To unsubscribe from this mail list, you must leave the OASIS TC
>>> that
>>> generates this mail. Follow this link to all your TCs in OASIS
>>> at:
>>>
>>> https://www.oasis-open.org/__apps/org/workgroup/portal/my___workgroups.php
>>>
>>> <https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>
>>>
>>> .
>>>
>>>
>>>
>>> --
>>> ==============================__=====
>>> Associate professor of Legal Informatics
>>> School of Law
>>> Alma Mater Studiorum Università di Bologna
>>> C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/
>>> Palazzo Dal Monte Gaudenzi - Via Galliera, 3
>>> I - 40121 BOLOGNA (ITALY)
>>> Tel +39 051 277217
>>> Fax +39 051 260782
>>> E-mail monica.palmirani@unibo.it
>>> ==============================__======
>>>
>>>
>>>
>>> ------------------------------__------------------------------__---------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail. Follow this link to all your TCs in OASIS at:
>>>
>>> https://www.oasis-open.org/__apps/org/workgroup/portal/my___workgroups.php
>>>
>>> <https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>
>>>
>>>
>>
>>
>> --
>> ===================================
>> Associate professor of Legal Informatics
>> School of Law
>> Alma Mater Studiorum Università di Bologna
>> C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/
>> Palazzo Dal Monte Gaudenzi - Via Galliera, 3
>> I - 40121 BOLOGNA (ITALY)
>> Tel +39 051 277217
>> Fax +39 051 260782
>> E-mail monica.palmirani@unibo.it
>> ====================================
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> --
>
> /chet [§]
> ----------------
> Chet Ensign
> Director of Standards Development and TC Administration
> OASIS: Advancing open standards for the information society
> http://www.oasis-open.org
>
> Primary: +1 973-996-2298
> Mobile: +1 201-341-1393
>
> Check your work using the Support Request Submission Checklist at
> http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html
>
> TC Administration information and support is available at
> http://www.oasis-open.org/resources/tcadmin
>
> Follow OASIS on:
> LinkedIn: http://linkd.in/OASISopen
> Twitter: http://twitter.com/OASISopen
> Facebook: http://facebook.com/oasis.open
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]