I suppose this type would inherit from CreativeWork? What additional field would it have?

Hi Matthias! Thanks for responding. You're right that a Decision type, similar to the Legislation type, would inherit from CreativeWork.

The Legislation type has several legislation-specific properties such as:

• legislationIdentifier (see url)
• legislationJurisdiction (see url)
• legislationType (see url)
• legislationDate (see url)
• legislationPassedBy (see url)
• legislationLegalForce (see url)
• legislationApplies (see url)
• legislationChanges (see url)
• legislationTransposes (see url)

Similarly, a Decision type could decision-specific properties such as:

• decisionIdentifier (e.g. ECLI 'ECLI:EU:C:2020:559')
• decisionCaseNo (e.g. case number 'C-311/18')
• decisionParallel (alternate identifiers, e.g. reporter citation 'NJ 2021/24')
• decisionJurisdiction (e.g. 'European Union')
• decisionType (e.g. 'judicial', 'decision' or 'arbitral')
• decisionDate
• decisionPassedBy (i.e. court or entity that decided the case, e.g. 'Court of Justice of the European Union')
• decisionPrecedent (i.e. validity of the precedent, e.g. 'valid' or 'overruled')
• decisionInterprets (i.e. neutral references to legislation and/or other decisions)
• decisionValidates (i.e. positive references to legislation and/or other decisions (confirm))
• decisionInvalidates (i.e. negative references to legislation and/or other decisions (overrule))

Most relevant general properties from the Thing and CreativeWork types:

• identifier (see url)
• name (e.g. parties nickname 'Data Protection Commissioner v Facebook Ireland Limited and Maximillian Schrems', see url)
• alternateName (e.g. popular nickname 'Schrems II', see url)
• datePublished (i.e. publication date, see url)
• author (e.g. 'Court of Justice of the European Union', see url)
• sourceOrganization (e.g. 'European Union', see url)
• abstract (e.g. decision summary, see url)
• about (e.g. field of law or EuroVoc, see metadata examples and url)
• citation (i.e. non-specified references, see url)

Relevant text properties from the CreativeWork type:

• text (i.e. document text, see url)
• inLanguage (i.e. document language, see url)
• workTranslation (i.e. document translation, see url)
• translationOfWork (i.e. authentic/main document, see url)

Relevant IP properties from the CreativeWork type:

• copyrightHolder (see url)
• copyrightNotice (see url)
• copyrightYear (see url)
• license (see url)
• sdPublisher (see url)

Other relevant fields from the Thing and CreativeWork types:

• description (see url)
• additionalType (i.e. more specific types from external vocabularies, see url)
• temporalCoverage (see url)
• genre (e.g. ; see url)
• creativeWorkStatus (see url)
• hasPart (see url)
• isPartOf (see url)

Metadata examples:

• https://schema.org/Thing#examples
• https://schema.org/CreativeWork#examples
• https://schema.org/Legislation#examples

In general, a Decision type would mimic how the Legislation type has been implemented to extend Schema.org functionality for legal decisions. Also take note of the WebContent type for web publications.

Would it make sense to have a common ancestor to both Legislation and Decision?
For instance legislationIdentifier could be shared.

Generally, there are many redundant fields, decisionDatePublished feel redundant given the fact that CreativeWork has datePublished, temporalCoverage for decisionDate etc.

I agree that decisionDatePublished is actually redundant and can easily be replaced by CreativeWork's datePublished. However, temporalCoverage doesn't exactly cover a precise decisionDate. Furthermore, I wouldn't mix legislation and decisions under a common legislationIdentifier as these are fundamentally different document types.

I have several ideas related to this issue. Please note that I am located in the U.S., so the following suggestions may not apply to the markup of, or reference to, the legal documents of other jurisdictions.

I agree wholeheartedly that there needs to be a Decision type. However, to fully realize the benefits of creating of this new type, there needs to be a corresponding creation of additional properties that will better complement the markup of legal documents like these. In particular, I am thinking of (A) the citation property and (B) the PublicationVolume type.

Most judicial decisions are published in bound volumes called "reporters." Because decisions are published in bound volumes, the Decision type should possess many of the same properties as the PublicationVolume type. With respect to the publication of legal decisions, there are both official and commercial reporters. Most judicial decisions are published in both official and commercial reporters. When citing a judicial decision in court filings, many courts require lawyers to cite to both the official and commercial reporter. When a case is published in more than one reporter, the citation to the non-official reporter is referred to as a "parallel citation."

For example, opinions of the U.S. Supreme Court are published in no fewer than three different reporters: (1) the United States Reports (this is the official reporter, and abbreviated "U.S."); (2) the Supreme Court Reporter (commercial reporter published by Westlaw, and abbreviated "S. Ct."); and (3) United States Supreme Court Reports, Lawyers' Edition 2d (commercial reporter published by LexisNexis, and abbreviated "L. Ed. 2d").

The anatomy of a case citation consists of the following elements, in order: (1) case name; (2) volume number of the bound volume in which the decision appears; (3) reporter abbreviation; (4) first page of the decision; (4.5) the specific page or page range of the decision being referenced, if so referenced (these are called "pinpoint citations" or "pincites"); and (5) year of the decision.

An example of a citation without pincites is: McNeill v. United States, 563 U.S. 816, 131 S. Ct. 2218, 180 L. Ed. 2d 35 (2011).

With pincites, the citation might read: McNeill v. United States, 563 U.S. 816, 820, 131 S. Ct. 2218, 2221-2222, 180 L. Ed. 2d 35, 36 (2011). (Note the page range used for the S. Ct. citation. Because each bound volume is paginated differently, it is possible that the cited content that appears on a single page in one reporter could appear on multiple pages in another reporter. )

The peculiar thing about legal citations, is the foregoing citation is considered a single citation, even though it technically contains citations to three different books containing a printed version of the decision. The Decision type should account for these peculiarities. To this end, I propose the following corresponding properties should be created:

For the Decision type:

• official -- Indicates that the citation is to the official citation/reporter -- expected type: PublicationVolume
• parallel -- Indicates that the citation is to a parallel citation/reporter -- expected type: PublicationVolume

For the PublicationVolume type:

• pincite -- Indicates a reference to a pincite that consists of a single page
• pinciteRangeStart -- Indicates a reference to the first page of a pincite that consists of a range of pages. Note: this is distinct from the pageStart property, which describes the page on which the work begins, whereas pinciteRangeStart describes the beginning of a specific portion of the work.
• pinciteRangeEnd -- Same as above, but with respect to the last page of a pincite that consists of a range of pages. Same note as above, but with respect to the pageEnd property.
• reporterAbbreviation -- Indicates the reporter to which citation is made. The content should be only the abbreviation of the reporter.
• dateDecided -- Self-explanatory; while the <time> element's datetime attribute could be set to the full YYYY-MM-DD date of the Decision, the content of the property need only be the year of Decision.

Using the citation containing pincites above, here is what I think an example citation might look like:

<html>
  <body itemscope itemtype="https://schema.org/Decision">
    <p>
      <cite itemprop="citation" itemscope itemtype="https://schema.org/Decision">
          <span itemprop="name">McNeill v. United States</span>,
          <span itemprop="official" itemscope itemtype="PublicationVolume">
              <span itemprop="volumeNumber">563</span>
              <span itemprop="reporter">U.S.</span>
              <span itemprop="pageStart">816</span>, 
              <span itemprop="pincite">820</span>,
          </span>
          <span itemprop="parallel" itemscope itemtype="PublicationVolume">
              <span itemprop="volumeNumber">131</span>
              <span itemprop="reporter">S. Ct.</span>
              <span itemprop="pageStart">2218</span>,
              <span itemprop="pinciteRangeStart">2221</span>&ndash;<span itemprop="pinciteRangeEnd">2222</span>,
          </span>
          <span itemprop="parallel" itemscope itemtype="PublicationVolume">
              <span itemprop="volumeNumber">180</span>
              <span itemprop="reporter">L. Ed. 2d</span>
              <span itemprop="pageStart">35</span>,
              <span itemprop="pincite">36</span>
          </span>
          (<time datetime="2011-06-06" itemprop="dateDecided>2011</time>).
      </cite>
    </p>
  </body>
</html>

@MaxwellDAnderson while your suggestion might suit the needs of common law jurisdictions, it is not suitable as a global standard. For example, it doesn't account for the differing needs of the many civil law or other jurisdictions which may not (so heavily) rely on reporters.

Instead of overfitting a Decision type on common law requirements, I think the focus should be on common standard-setting! Therefore, I believe it would be better to see how a Decision type could meet more general requirements. Maybe it would be good to refer to the European Legislation Identifier program and its implementation in Schema.org for inspiration?

@romjansen I understand your issue to be merely with the word "reporter." I interpret your lack of direct response to any of the other proposed additions to the PublicationVolume type as a tacit agreement with these suggestions.

With respect to the "reporter" issue, I amend my proposal to eliminate the suggested implementation of reporterAbbreviation and replace it with legalSourceAbbreviation. This better captures the intended meaning of referring to the abbreviation of a repository in which legal documents are published and which serves as a source of law. This includes not only case law reporters, but also legal codes, official gazettes, official journals, administrative registers, etc.

I was reminded of a publication titled "Guide to Foreign and International Legal Citations," published by NYU's Journal of International Law and Politics. The guide surveys the citation practices of 45 jurisdictions. A perusal of the guide reveals that two things are relatively universal: (1) abbreviations are commonly used in legal citations; and (2) legal documents are routinely published in specific locations (CTRL + F "reporter", "reports", "gazette", and "code"). These observations are true across common-law, civil-law, and Islamic-law jurisdictions.

For me, it would seem a bit odd for a schema used for describing legal decisions to lack a mechanism for informing the reader of where that decision is published or where other decisions cited within the decision are published. If the intended users of this schema are not members of the legal profession, then such an omission might make sense. But if I am correct that members of the legal profession are the intended users of the schema, then we should ensure they have the ability to describe the relevant aspects of their documents.

I have been reviewing ELI for the past week or so. I am curious why the European Case Law Identifier (ECLI) was not chosen as the inspiration for the Decision type?

DCMI's bibo ontology also looks very promising. We could pull from there as well; they have lots of good ways to describe Decisions of various kinds.

@MaxwellDAnderson thanks for your quick reply. I don't see any problem with extending the PublicationVolume type with some new properties to better suit the needs for jurisdictions which mostly cite their judicial decisions through reporters, official gazettes, official journals, etc. Also, I think the addition of pincites is a clever idea! One sidenote; European jurisdictions would mostly refer to paragraph numbers instead of page numbers since web publication without page numbers is gradually becoming the new publication standard.

Regarding your comment on NYU's Guide to Foreign and International Legal Citations; if we look at the Bluebook page for the Netherlands you'd think that the Netherlands also cites their judicial decisions through reporters. However, you'd be mistaken as this is a bit misleading. Reporters were indeed a citation standard back in the day, but ECLI has since replaced them as the new citation standard to refer to judicial decisions while reporters are mostly referred to for their commentary on judicial decisions. This is true for most EU member states (see current implementation overview).

Moreover, not every judicial decision is published in a reporter and European reporters are generally commercial with their content hidden behind a paywall. In contrast to common law jurisdictions where a judicial decision published outside certain official reporters might be regarded as 'unpublished' (impacting its value as a precedent before court), this distinction is not made by most civil law jurisdictions where judicial decision are treated as equal precedent whether they are published in reporters or not.

Concluding, I do think that ECLI should be an inspiration for the Decision type! Maybe I was unclear about that with my reference to ELI, but that was purely indicative of how a similar program has been implemented as the Legislation type to extend Schema.org functionality for legislation. The Decision type should preferably identify judicial decisions using a Uniform Resource Identifier (URI) such as ECLI or, if not available, the main or preferred reporter citation. Alternative publication locations could be added under an additional property. This would make the Decision type more flexible to suit differing citation standards. For example, look at the official publication of this Dutch landmark decision ECLI:NL:HR:1965:AB7079 where a clear distinction is made between the ECLI and other (unofficial) publication locations (transl. 'vindplaatsen').

@romjansen thank you for this additional background. I wholeheartedly agree that a URI and the ability to cite other other publications, such as reporters, certainly can, and should, co-exist. I think those two aspects of the proposed Decision class will ensure the class is utilized by a wide range of legal professionals. I also believe the creation of the pincite property will complement both of these well. As you mentioned, many European cases (and select jurisdictions in the U.S., too) cite to paragraph numbers. Ideally, the pincite property could be used to refer to any discrete subdivision of a document, including pages, articles, sections, paragraphs, subparagraphs, lines, sentences, clauses, etc.

The legalSourceAbbreviation property I proposed in my previous comment could be used to refer to not only judicial decisions, but also things like statutes and regulations. For instance, in the U.S., the code in which federal laws are published is called the "United States Code," which is abbreviated "U.S.C." The whole term "United States Code" is almost never spelled out in legal documents, so even Thing's name property is not precisely applicable. To your point, the ELI and ECLI used by the EU would likely not benefit from this property, since all of the relevant abbreviations appear in the identifier itself. The only exception might be if one of the documents cites to another document outside of the ELI/ECLI universe.

I like the decisionInterprets, decisionInvalidates, and the decisionValidates properties you mentioned in one of your initial comments. Particularly the decisionInterprets property--that is really the kind of good semantic information that is invaluable and helps distinguish the thing being interpreted from an ordinary citation. I perceive the decisionInvalidates and decisionValidates as falling under the general banner of "decision disposition information" (i.e., what is the ultimate outcome of the case). While most cases certainly are either validated (which I take could be used to describe a decision that has been "affirmed") or invalidated (which I take could be used to describe a decision that has been "overruled"), there are at least two additional outcomes that I can think of: (1) a decision being vacated (i.e., annulled or like the previous decision never happened) and (2) a case being remanded (i.e., sent back to a lower court to, for example, apply a legal standard in a manner consistent with the decision of the higher court). I bring this up because I would imagine there are an infinite number of different disposition types and combinations.

Additionally, there are other dispositions that I can think of that are not strictly tied to decisions, such as revocation, superseding, amending, continuing, supplementing, etc. It is also possible that dispositions of the same type will have a different scope, such as a decision that is only partially validated or invalidated.

I am curious what your thoughts are on possibly replacing decisionInvalidates and decisionValidates with a more general dispositionType and dispositionScope property of the Thing class? Or, if not outright replacing decisionInvalidates and decisionValidates, perhaps adding dispositionType and dispositionScope to Thing to ensure that dispositions falling outside of the validates/invalidates dichotomy could, nevertheless, be described? Alternatively, we could simply add more decision[Disposition] properties to account for some of the most common disposition types?

@romjansen -- I am not sure if there has been any movement on this issue, but I did put together this repository that contains an initial implementation of what this schema type might look like. It contains a heavily documented RDF file, as well as a documentation webpage generated by Protégé.

Feel free to download and make changes to the RDF file or open a pull request!

This issue is being nudged due to inactivity.