Re: [legalcitem] Template for use cases with some examples

[Fabio Vitali <fabio@cs.unibo.it>]

Dear Chet, 


briefly, as it is already 1 AM here: 

* the example you cite in indeed interesting, but, you prove my point that it talks about a document and not actors nor contexts. So "usual" use cases would not help. Adding details to users, businesses, contexts, actions and task, or in general to anything BUT the document or its history, would not help understanding the use case better or solve it more brilliantly. So this is not an "usual" use case. 
* I don't know hot Legal Cite will solve the riddle, I know how the Akoma Ntoso Naming Convention would: in short, FRBR is your friend. 
* the basic rule in AKN NC is that any selection of content is an Expression. This means that any individual version of the document in which ONE possible variant of the same structure exists, is an Expression, and any composite version in which you have two or more variants present at the same time, is also an Expression. You can have as many Expression as you want, with any content that you feel like having, because you can be the author of the Expression, even if you are not the author of the Work.  
* Identical section numbers happen in other jurisdictions, too (although I don't know of another example of FIVE different sections having the same number!!!) It is not the purpose of the markup authors to fix the errors of the legislator and solve the inconsistency, but just to expose it and propose ways to make systems work despite the inconsistency. This means that, without changing the visual aspect of the document and keeping the visible numbers created by the legislator, the markup author needs to provide different ids to each variant of the section. 
* Akoma Ntoso provides three different ids for each element, only one of which really must be unique: the expression id (eId) is the unique id of the section, and must be different: the markup author will decide WHICH (including none) is the REAL section So an So, and will use the plain rId for that one (or for none). Then the wId (work id) is the id of the theoretical element that the concrete element claims to be. Usually the coincide, in this case they do not, and therefore the wId will for all of them the id they would have IF they were the only section with that number.
* Authors of links might be aware of the situation or not. If they are, they will examine the ids and choose the one that points to specific variant they mean to link. Otherwise, they will use an id derived on the number of the section, which will match with the wId of many different sections. 
* Finally, link resolvers must work with whatever information you gave them, and ask the user if insufficient. Thus, if resolving a reference using either the eId or the wId returns a single element then THAT is the destination, and if it returns two or more results, then either both must be shown, or the user must be asked to choose. 

Ciao

Fabio

--

Il giorno 16/apr/2014, alle ore 00:29, Chet Ensign <chet.ensign@oasis-open.org> ha scritto:

> Fabio, maybe you could give some counter examples of how this would like. 
> 
> I believe that we very much need user/business requirements so that we know what we are up against. 
> 
> Let me ask, for example, about the situation, sadly all to common in certain states in the U.S. (Texas and New York being the nightmare examples where I remember the editors holding up the published statues and asking "how are you going to deal with this??) where several bills passed during the legislative affect the same exact section of the statutory code in inconsistent if not downright contradictory way and so now there are identical (5) 9.3.A sections of the code that people must be able to cite to. The one example that remains vividly in mind was a section that, after codification and publication, had 5 identical section numbers. One was a future change that *might* come into affect if the legislature passed these other things, two others tried to make essentially the same modification to the section of the code but used irreconcilable synonyms and one that was just in the wrong place (oops - that was supposed to be in the chapter covering motor vehicles but somebody transposed their numbers and it wound up in the section governing animal husbandry instead). 
> 
> I'm not sure how the approach you describe would enable me to say "we need a solution that can address that mess." 
> 
> I think a corresponding example will help. 
> 
> Thx, 
> 
> /chet 
> 
> 
> On Tue, Apr 15, 2014 at 5:42 PM, Fabio Vitali <fabio@cs.unibo.it> wrote:
> Dear Chet,
> 
> It seems to me, I might be wrong, that the schema you propose is a template for application-oriented use cases, where specific actors perform specific tasks using a specific tool to obtain specific results.
> 
> I fear that this may provide non-useful information and may not let emerge other more meaningful information. Use cases, in particular, are meant to express clearly and vividly how the to-be-implemented tool will be used to satisfy an important user goal.
> 
> For instance, actors and contexts, which are key aspects of use cases in the requirement analysis of software engineering, do not seem particularly relevant here: the use case describing a specific actor in a specific context examining a citation that is well-formed and fully understandable seems identical to the use case of a specific actor in a specific context examining a citation that is ill-formed and hardly understandable, except for the fact that one is well formed and the other is well formed, which has nothing to do with neither the specific actor nor the specific context.
> 
> What we need to find out, I believe, is how citations are formed, how can they be described as well-formed and how they are ill-formed, and how to determine the relevant document given the citation.
> 
> As such, I believe that it is not appropriate to consider tools for functional requirements of software tools, but rather to the even more ancient and arcane methodologies for subject classifications used in library science. Check for instance Library Classification on wikipedia.
> 
> Library science authors describe classification scheme as either enumerative or analytico-synthetic. Enumerative classifications employ a top-down approach, so as to organize and structure the overall corpus into narrower parts until the content of each part describes a specific concept. Analytico-synthetic classifications identify in a bottom-up fashion the basic concepts for each element of the collection being organized, and from the resulting concepts generate a schema to arrange them in a classification.
> 
> >From this perspective, the technical SC should try to produce the borderlines and master approaches of an enumerative schema, while the individual SC should be considering the analytico-synthetic approaches, so as to identify in their variability the domain of documents they are in charge of.
> 
> Rather than describing people and contexts, therefore, they should describe types of documents, and the facets (also check Faceted classification on wikipedia) they can be described by. The subjects are the documents, the outputs are the relevant facets and the vocabulary of values such facets may assume, starting with the most frequent and "normal" examples and rapidly navigating towards the exceptions, the hybrids, the borderlines, the monsters.
> 
> I believe that a reasonable structure therefore should go as follows:
> 
> Document Type Name: a descriptive name for the document
> 
> Used in: the country, other geographical and jurisdictional determinations, offices and contexts
> 
> Description: a brief and poignant description of the document's purpose, nature and variability
> 
> Facets (attributes, property, features): the set of "clearly defined, mutually exclusive, and collectively exhaustive aspects, properties or characteristics of a class or specific subject"
> 
> Vocabularies: for each facet, the nature, type and if possible exhaustive list of values that each facet my be described by.
> 
> Examples: a few simple examples (to express in its width the variability of the normal cases), and as many borderline, monster and peculiar examples as possible.
> 
> Support material: in my experience, cover pages, colophons, and tables of content contain the core of the information relevant to describe a document.
> 
> For instance, being able to assign all the elements of a cover page to one facet or another would already be an important way to verify the correctness and completeness of one's job.
> 
> That's all, I think
> 
> Ciao
> 
> Fabio
> 
> --
> 
> 
> Il giorno 15/apr/2014, alle ore 18:09, Chet Ensign <chet.ensign@oasis-open.org> ha scritto:
> 
> > LegalCiteM members,
> >
> > A bit later than promised however, attached, please find a sample use case template for review and discussion. We roughed this out last week and I think it strikes a balance between simplicity on one hand - not driving down into too much detail - and sufficiency on the other - each can clearly spell out a business or technical need in enough detail for us to (a) decide whether the output produced by the TC should enable the use case to satisfied and (b) determine whether or not proposed solutions actually do.
> >
> > The fields of the use cases are:
> >
> > 1. Title - a short, descriptive name for the use case
> >
> > 2. Description / user story - the broad description of what someone wants to accomplish
> >
> > 3. Example - a specific example of the user story in practice
> >
> > 4. Goal - what the result of the application of a legal citation standard to the user story would produce
> >
> > 5. Actors - the participants in the user story
> >
> > 6. Dependencies - essentially the bits that would have to be in place in order to enable the user story to be satisfied
> >
> > 7. Assumptions - any assumptions about how the world works that underlies the user story
> >
> > Perhaps we can discuss this template and the examples at tomorrow's meeting?
> >
> > Best,
> >
> > /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
> > <legal-cite-sample-usecases-ver2.txt>
> > ---------------------------------------------------------------------
> > 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
> 
> 
> 
> --
> 
> Fabio Vitali                            Tiger got to hunt, bird got to fly,
> Dept. of Computer Science        Man got to sit and wonder "Why, why, why?'
> Univ. of Bologna  ITALY               Tiger got to sleep, bird got to land,
> phone:  +39 051 2094872              Man got to tell himself he understand.
> e-mail: fabio@cs.unibo.it         Kurt Vonnegut (1922-2007), "Cat's cradle"
> http://vitali.web.cs.unibo.it/
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> /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



--

Fabio Vitali                            Tiger got to hunt, bird got to fly,
Dept. of Computer Science        Man got to sit and wonder "Why, why, why?'
Univ. of Bologna  ITALY               Tiger got to sleep, bird got to land,
phone:  +39 051 2094872              Man got to tell himself he understand.
e-mail: fabio@cs.unibo.it         Kurt Vonnegut (1922-2007), "Cat's cradle"
http://vitali.web.cs.unibo.it/