Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Legislation : Proposed extension #1156

Closed
tfrancart opened this issue May 11, 2016 · 95 comments
Closed

Legislation : Proposed extension #1156

tfrancart opened this issue May 11, 2016 · 95 comments
Labels
schema.org vocab General top level tag for issues on the vocabulary status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area.

Comments

@tfrancart
Copy link
Contributor

tfrancart commented May 11, 2016 •
edited

Update : see extension v3 below (09 november 2016)

A proposed extension to describe Legislation within schema.org has been published at http://legal.eli-legislation-schemaorg.appspot.com/Legislation.
Additional material and use-cases description can be found on the extension page (examples still needed). The proposal was announced on the mailing-list.

The extension includes the following classes and enumerations :

  • Legislation (subclass of CreativeWork) "A legal act or a component of a legal act (like an article).", with 24 new properties.
  • LegislationObject (subclass of Legislation and MediaObject) "A specific object or file containing a Legislation. Note that the same Legislation can be published in multiple files. For example, a digitally signed PDF, a plain PDF and an HTML version."
  • LegalValueLevel "A list of possible levels for the legal validity of a legislation."
  • LegalForceStatus "A list of possible statuses for the legal force of a legislation."

The diagram below gives an outline of the extension :

schemaorg-diagram-only-v8

This extension proposal comes with suggestions to improve the core schema :

This extension is adapted from the European Legislation Identifier (ELI) ontology. The ELI development is driven by national legal publishers of some European countries, and by European institutions, all aiming at identifying, describing and linking legislation on the web. For more information on ELI, see the ELI register.

We would love to get feedback from the community on this proposal to improve the description of legislation with schema.org. Our objective is that this proposal be integrated either as a hosted extension, or even in the core.
@tfrancart tfrancart mentioned this issue May 11, 2016
Open
@danbri
Copy link
Contributor

danbri commented May 11, 2016

Thanks for the comprehensive proposal! One of the best documented we've received :)

@tfrancart
Copy link
Contributor Author

Thanks, we hope this can make it through to become a hosted extension, then !
As indicated on the mailing list I can repackage this if needed as pull request(s), "pending" extension, branches, split things, etc. Just let me know what would be the easiest to progress.

@danbri danbri added schema.org vocab General top level tag for issues on the vocabulary type:exact proposal status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area. labels May 11, 2016
@tfrancart tfrancart mentioned this issue May 11, 2016
Open
@akuckartz akuckartz mentioned this issue May 17, 2016
Open
@johndann
Copy link

Hi Thomas, Hi Dan,
Just a short message to support the Extension, for a lot of Official Journal it would be very important this issue goes through. Easy access and better search facilities would be essential to provide a better service to civil society and businesses.
John

@danbri
Copy link
Contributor

danbri commented Jun 3, 2016

I'm inclined to explore this as a foundation for something like "legal.schema.org" covering both the description of legislation but also other aspects e.g. case law / court documents, which @stuartrobinson and others have been looking into. That would be consistent with what we've done for the medical/health parts of schema.org, which have recently moved into a fairly broad "health-lifesci.schema.org" area that provides room for related schemas to also be added. How does that sound?

@tfrancart
Copy link
Contributor Author

I have nothing against a broader "legal.schema.org" extension, with legislation as a basis. However the legislation part should move forward without waiting for other topics to be finalized; from the point of view of the ELI initiative, the sooner the legislation proposal is discussed, the better.

How do you think we can make progress on this ? (I can rework the proposal to use "legal.schema.org" instead of "legislation.schema.org", if needed).

On case law / courts, the ECLI metadata set (http://eur-lex.europa.eu/legal-content/GA/TXT/?uri=celex:52011XG0429%2801%29) - derived from DC - can be taken as a starting point or source of inspiration.

@akuckartz
Copy link

As noted in #980 (comment) this is also related to #448. For the moment I simply refer to http://www.popoloproject.com/ to demonstrate what kind of data these efforts are about,

@johndann
Copy link

johndann commented Jun 8, 2016

Hi Dan,

It would be interesting to broaden the scope to other parts, but it will take a considerate amount of time to finish that work.
There is a an good understanding and agreement on the "legislation" part - the solution proposed by Thomas is of course discussed at a broader level with quite a lot of Member States within the Official Journals - and we would like to move forward.

Could there be different sub-parts of "Legal.schema.org" e.g. Legislation, case law, court documents etc ... which could advance at is own pace ?

Thanks,
John

@mwkuster
Copy link

mwkuster commented Jul 1, 2016

Hi Dan, John,

having timely support for a Legislation class in schema.org is of great interest for the publication of European legislation by the Publications Office of the European Union.

Covering all things legal in one go risks to be complex and take a long time, as the concrete challenges of, e.g. case law or doctrine would all already have to be analyzed at this stage. For this reason I agree with John here that the best strategy is to agree on support for legislation first and then think about extensions to other types of legal resources in response to concrete use cases.

Best regards

Marc (Küster)

@tfrancart
Copy link
Contributor Author

Hello

As @danbri suggested, I have renamed the extension from "legislation.schema.org" to "legal.schema.org", and updated the RDFa accordingly. The correct link to it is now http://legal.eli-legislation-schemaorg.appspot.com/Legislation.

To make concrete progress on this, I propose that :

  • the "Legislation" type be integrated in the core schema;
  • the rest of the proposed extension be discussed either here or on joinup or on the extension issue tracker on Github; maybe a subset of the extension can be integrated first and the more problematic features/properties can be left for tuture versions ?

Cheers

@tfrancart
Copy link
Contributor Author

Ha, and by the way, I have also added 2 markup examples to http://legal.eli-legislation-schemaorg.appspot.com/Legislation.

@twamarc
Copy link
Contributor

twamarc commented Jul 4, 2016 •
edited

Hi @tfrancart;
I have a very general question regarding the extension terms.
Some of them sound very general and my be used outside this extension, or at least someone would misuse them for other mark ups. Is it feasible to have them more specific for legal domain? (maybe adding legal inside each one--only where it can be suitable-- just thinking loud here I think we need more thoughts)
eg. (just what I picked up, I did not make a deep screening!):

http://legal.eli-legislation-schemaorg.appspot.com/appliedBy
http://legal.eli-legislation-schemaorg.appspot.com/applies
http://legal.eli-legislation-schemaorg.appspot.com/changedBy
http://legal.eli-legislation-schemaorg.appspot.com/basedOn
http://legal.eli-legislation-schemaorg.appspot.com/basisFor
http://legal.eli-legislation-schemaorg.appspot.com/citedBy
http://legal.eli-legislation-schemaorg.appspot.com/cites
http://legal.eli-legislation-schemaorg.appspot.com/consolidatedBy
http://legal.eli-legislation-schemaorg.appspot.com/consolidates
http://legal.eli-legislation-schemaorg.appspot.com/dateVersion
http://legal.eli-legislation-schemaorg.appspot.com/responsibilityOf
http://legal.eli-legislation-schemaorg.appspot.com/publishedIn

etc.
Just my 2cents!
~Marc

@tfrancart
Copy link
Contributor Author

Hi @twamarc

Thanks for the feedback. A naming review wrt to SDO rules and existing properties is required. I am not totally aware of the SDO policy regarding naming of properties in extensions. Does the fact that they are in an extension is enough to disambiguate the properties ? otherwise we are open to more specific naming with "legislation" inserted in property names :

  • changes / changedBy -> legislationChanges / legislationChangedBy
  • appliedBy / applies -> legislationAppliedBy / legislationApplies
  • basedOn / basisFor -> legislationBasedOn / legislationBasisFor
  • etc.

Should I try to be as precise as possible in the naming of every properties to avoid any potential name clashes ?

@twamarc
Copy link
Contributor

twamarc commented Jul 4, 2016

Am happy with proposed terms (of course am not in the domain---others can argue here). The fact that they are in an extension is NOT enough to disambiguate the properties, we have the same problem in health-lifesci.schema.org; and renaming them after publication is very expensive (I mean in terms of technicalities/functionality maintenance/backwards compatibility, etc)
It would be nice to ship this extension already fixed and that will avoid confusion, misuse and also names clashes.

@RichardWallis
Copy link
Contributor

@tfrancart Although the documentation of the terms will be in an extension subdomain the canonical url of the term will be http://schema.org/{term} so as @twamarc indicates being in an extension does not disambiguate terms.

Comments on a brief view of terms supplied:

@GerryMatthews
Copy link

On behalf of the electronic Irish Statute Book (eISB), I would like to support this proposal. I also echo the comments of John and Marc Kuster above with regard to having timely support for a Legislation class in schema.org and its subsequent benefits to publishers of legislation.

I would hope that we can agree on support for legislation first and then think about extensions to other types of legal resources.

Regards - Gerry Matthews - eISB project team - Ireland

@thadguidry
Copy link
Contributor

thadguidry commented Jul 5, 2016 •
edited

@tfrancart @RichardWallis @danbri
I have to agree with others that this should move forward as Legislation. Where we can tackle Legal within another extension later.

@tfrancart Make use of more hyperlinks in the descriptions to make things more clear. "...use the property transposes." Where transposes should be a hyperlink to the property itself.

Its important to note the 2 domains as being related but not equal:

Legal = Law
and
Legislation = Prior to becoming Law.

"When you talk about law, there are two sides of it in the context of Govt. — Legislation & Regulations. Legislation is a bill that becomes a law, and Regulation is the law. "

@tfrancart @jpmckinney Does your effort align with James McKinney's efforts on International Open Government Data Specifications - Popolo ? http://www.popoloproject.com/specs/motion.html#classes-and-properties

@akuckartz
Copy link

This issue was raised less than two months ago. I am in favor of the effort but against accepting this hastily. It should be aligned with the other efforts and requirements mentioned before (#1156 (comment)). I will provide more details in a few days.

@johndann
Copy link

johndann commented Jul 6, 2016

Hi all,

@akuckartz I would like to react to the fact that the proposition has been introduced "only a month a go and not react hastily". We have been working on ELI and Legislation for the past 5 years, and only when we thought to be ready we introduced it at schema.org Our propositions are based on real use cases within a lot of Official Journal publishers ...

Of course there is always place for improvement.

@thadguidry
I think the definitions need to be more discusses: For me "Legal" is more an adjective. In case would use "Law" in its very general understanding. And "Legislation" is a set of legal acts proposed by Governments or other legal institutions .. which suits here ... Wikipedia seems to have nice definitions ...

@tfrancart
Copy link
Contributor Author

tfrancart commented Jul 6, 2016 •
edited

We dont want to take decisions hastily, but we would like to see this discussed and move forward, and idealy have some visibility on the process; the comments received recently are very positive. As seen also in the comments above, large publishing institutions are interested in this to make legislation more visible on the web and interlink it.

Let's try to summarize where we stand :

  • we are happy with "legal.schema.org" as long as the legislation part can be introduced first without waiting for case-laws, etc. Who decides ?
  • I am in favor of introducing the type "Legislation" in the core and the rest in the extension; who decides ?
  • we need to disambiguate the terms as much as we can; I will come back to you with a proposal;
  • we need to adress the comments of @RichardWallis;
  • we need to compare with Popoloproject to see if/how it relates;
  • it is better if hyperlinks are used in the definitions (I think I already tried and it didn't worked, will come back to you on this);

@tfrancart
Copy link
Contributor Author

tfrancart commented Jul 6, 2016 •
edited

Hyperlinks are now included in the definitions.
Looking at http://www.popoloproject.com/, I don't see an overlap : the proposed extension here adresses the markup of legislation texts published on the web (usually by official legal publishers, but could also be by private re-publishers), while my understanding of Popolo is that it adresses the legislative process by itself (Motion, Vote, etc.), the output of which may be a Legislation.

@RichardWallis
Copy link
Contributor

  • Hyperlinks Only a minor point, are you using the Markdown Syntax Text or [[Schema-Term]] it is much easier to edit / view in the description source
  • Who decides? The community. Consensus in the group backing the proposal as to the general sense of the proposal; followed by broader consensus when the proposal becomes a Pull Request; with a final approving consensus from the steering group as they review the next release of the vocabulary. Checkout How we work.

Note from experience: Consensus often consists of +1s from the most interested, few or no -1s and silence from the remainder. Lack of consensus is usually the more obvious state ;-)

@tfrancart is right to point out that the prime purpose of Schema.org is to markup and therefore share information on the web about Things (in this case legislation texts). It is tempting to start applying it to 'internal processes' of a particular domain using it to address questions across the whole problem space. That may well be a fruitful direction to take in the future but it is not necessarily the best place to start. Taking input from initiatives such as Popolo is valuable to help set direction and hopefully avoid future term and modelling conflicts. Introducing an extension into Schema.org is best handled as an iterative evolving process - learning from adoption, usage, usage by associated domains, and experience over a few Schema release cycles.

@mwkuster
Copy link

Then let me note my +1 for the proposal :-)

@tfrancart
Copy link
Contributor Author

Hello

Here is a proposal for renaming the properties to disambiguate them; basically prefixing everything with "legislation" :

Initial proposal Proposed Renaming
appliedBy legislationAppliedBy
applies legislationApplies
basedOn legislationBasedOn
basisFor legislationBasisFor
changedBy legislationChangedBy
changes legislationChanges
citedBy legislationCitedBy
cites legislationCites
consolidatedBy legislationConsolidatedBy
consolidates legislationConsolidates
dateEntryIntoForce legislationDateEntryIntoForce
dateLegislation legislationDate
dateNoLongerInForce legislationDateNoLongerInForce
dateVersion legislationDateVersion
legalForce legislationLegalForce
legislationIdentifier legislationIdentifier
legislationType legislationType
legislationVersion legislationVersion
passedBy legislationPassedBy
publishedIn legislationPublishedIn
relevantArea legislationRelevantArea
responsibilityOf legislationResponsible
transposedBy legislationTransposedBy
transposes legislationTransposes

before actually applying the change to the proposed extension, I would like to have feedback on the naming from experienced people like @twamarc, @RichardWallis or @danbri. Do you think proposed names are unambiguous enough ?

Won't this constraint of having unique property names in SDO lead to awkward naming in the long run ?

Cheers

@twamarc
Copy link
Contributor

twamarc commented Aug 24, 2016

@tfrancart as I am not a legislation domain expert I will just provide outsider's view based on the principle of having unambiguous terms only. Colleagues from legislation working team could finetune and take final decision of course. Saying that, I agree that now proposed names are unambiguous enough.
Although the terms legislationApplies , legislationPassedBy , legislationChanges and other based on verb-word like consolidatesare not clear to me. Maybe they have use-cases in domain.
What is the difference between legislationDateEntryIntoForce and legislationDate ?

My 2cents,
Marc

@danbri
Copy link
Contributor

danbri commented May 20, 2017 •
edited

Our approach at schema.org is that we agree

A modifies B is as important to know that B is modifiedby A

But we'd express it different. Rather:

If you know (or say) that "A modifies B", you also know (or you're also saying) that B modifiedBy A.

Sometimes, for added convenience/simplicity, schema.org names its properties in both directions. But this is not strictly necessary. For example, we name the relationship that connects a Person to the Place that they were born in the direction that begins with the Person and ends with the Place ("birthPlace"). And currently we do not name it explicitly in the other direction.

If you learn (by markup or equally, from human communication) that a Person called "Jane Doe" was born in a Place called "Bognor Regis", then you have also learned that the Place called "Bognor Regis" is where a Person called "Jane Doe" was born. Every natural language has different grammatical structures for handling this, but the underlying logic is similar. This is also true of markup languages. RDFa and JSON-LD have more built-in support for "writing things backwards"; but it is also possible to do so in Microdata. It might be worth spelling this out first.

Markup showing birthPlace of a Person, i.e. some Place

{ 
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "Jane Doe",
  "birthPlace":
  {
    "@type": "Place",
    "name": "Bognor Regis"  
  }
}

Markup showing 'birthPlace' written in reverse, i.e. starting with the Place.

a) using @reverse at the point the property is needed

{ 
  "@context": "http://schema.org/",
  "@type": "Place",
  "name": "Bognor Regis",
  "@reverse": 
    { 
      "birthPlace": 
         {
          "@type": "Person",
          "name": "Jane Doe"
         } 
    }
}

b) for the publisher of the markup to define their own inverse property

{
	"@context": ["http://schema.org/", {
		"birthPlaceOf": {
			"@reverse": "birthPlace"
		}
	}],
  "@type": "Place",
  "name": "Bognor Regis",
  "birthPlaceOf": 
     {
      "@type": "Person",
      "name": "Jane Doe"
     } 
}

(aside: I had thought Google supported this variant but I can't make it work right now; will investigate)

Even though schema.org didn't go to the trouble of naming another property in the opposite direction, e.g. birthPlaceOf, we can still express the same idea but start with the Place.

There are similar idioms in RDFa. In Microdata you have to use identifiers to cross-reference the Place and Person references together, and we are exploring new syntax improvements, but the idea is still there.

I mention all this not to prove anyone wrong, but rather to highlight the tradeoffs.

Currently schema.org (in the draft v3.3 release) has "consists of 589 Types, 865 Properties, and 114 Enumeration values". This is not gigantic, but consider these 1568 terms as a larger dictionary than the ~1500 terms used in Special English to broadcast Voice of America. We have to be careful about casually doubling the number of properties we choose to name, especially when they do not add any new information. To know that A was born in B, is just the same as knowing the B is the birthplace of A.

We have never written explicit guidelines around this for schema.org. Generally we are pragmatic. As you can see from the above, it is already possible for "Place-centric" markup to include a description of someone born there. However the syntax is certainly a bit more complicated than if we simply had included "birthPlaceOf" directly in Schema.org. That is roughly the intuition that has guided us as we develop and expand Schema.org. When the need arises, or new use cases develop (consider the http://webschemas.org/TouristAttraction improvements we have queued up for v3.3), then we can be pretty casual about adding inverse properties. However the basic assumption is that they are not something we do for every single property.

For now with the Legislation work, my advice is that we add them into the "Pending" area for wider review and early adopter implementation, as well as for exploration of related legal/civic vocabularies. But we should flag the choice of naming direction and the selection of inverses as something we pay attention to as we move towards incorporating this vocabulary in the core or in a "legal.schema.org" (or eg "civic.schema.org" or whatever) extension. I have no strong view on which properties ought to keep inverses, only that it worth some thought and that defaulting to every property being named in both directions can clutter the design and make the vocabulary seem more complex than it actually is.

Hope this helps!

/cc @chaals who is also thinking about this lately esp. w.r.t. @w3c Microdata spec.

@danbri
Copy link
Contributor

danbri commented May 20, 2017

Aside from the inverses question, @tfrancart can you comment on @johndann's remark about date applicability? i.e.

date_applicability (act signed on date A published on date B and applicable 3 months later

@stuartasutton stuartasutton mentioned this issue May 20, 2017
Closed
@tfrancart
Copy link
Contributor Author

(After internal discussion with @johndann and @mwkuster)

@danbri :

nothing in the underlying syntax (e.g. Microdata, RDFa or JSON-LD), or in Schema.org itself, supports that notion of a semi-inverse.

I was not asking for any specific syntax (or semantic btw); I was simply trying to make the point that sometimes inverse properties are useful because they carry an information : the direction in which the original assertion was made.
Besides, sometimes people can simply be used to a business term in the other direction than the one schema.org chose, thus making it a little difficult to find the correct property in the vocabulary.
All of this to say the statement "inverse properties is bad design" - as I read elsewhere - may not always be true.

Currently schema.org (in the draft v3.3 release) has "consists of 589 Types, 865 Properties, and 114 Enumeration values". This is not gigantic, but consider these 1568 terms as a larger dictionary than the ~1500 terms used in Special English to broadcast Voice of America. We have to be careful about casually doubling the number of properties we choose to name

Understandable. Agreed.

For now with the Legislation work, my advice is that we add them into the "Pending" area for wider review (...). But we should flag the choice of naming direction and the selection of inverses as something we pay attention to as we move towards incorporating this vocabulary (...). I have no strong view on which properties ought to keep inverses, only that it worth some thought and that defaulting to every property being named in both directions can clutter the design and make the vocabulary seem more complex than it actually is.

We agree with proceeding to pending, and then review proposed inverse properties. Especially regarding the proposed links between Legislation (legislationChanges/legislationChangedBy, legislationConsolidated/legislationConsolidatedBy, legislationApplies/legislationAppliedBy, legislationTransposes/legislationTransposedBy), since both their domain and range is Legislation, it won't make it harder to find the correct property if we drop the inverse and keep only one.

@johndann : dateApplicability was out of scope of our proposal (based on ELI 1.0). It can still be suggested later, of course.

@danbri
Copy link
Contributor

danbri commented May 22, 2017

Thanks, @tfrancart. There is little to disagree with here, although we might sometime look again into the "direction in which the original assertion was made" aspect. It is possible that tools (e.g. certain kinds of RDF database) might automatically add in the inverse version of each asserted claim.

Anyway It sounds like we have a sensible plan agreed for now. And thank you for pointing out the Legislation-to-Legislation inverses, those do sound like a good focus for future review.

@f1234k
Copy link

f1234k commented Jul 10, 2017

Can we start using everything that is described here in our websites? What is the timeline of the adoption status in official schema.org definitions?

@ghost
Copy link

ghost commented Jul 10, 2017 via email

@tfrancart
Copy link
Contributor Author

"jurisdiction" is intended to be covered by the generic property "spatialCoverage". If need be, we could create a subproperty. Note that there are various legal notions that are spatial-related : jurisdiction, sovereignty, applicability or administrative area.

I don't quite get the rest of the comment. The type "Legislation" is intended to represent "one law" (an act, a decree, a bill, etc...), it is a subclass of CreativeWork, it is a document; it does not represent an abstract "legal principle".

@ghost
Copy link

ghost commented Jul 11, 2017 via email

@thadguidry
Copy link
Contributor

@tfrancart Then let's tweak the description of Legislation just a bit so that we account for that intent and make it clearer for others that our Legislation is about a legal document such as those you mention.

I suggest this new description for Legislation
"A legal document such as an act, decree, bill, etc (enforceable or not) or a component of a legal act (like an article)."

@tfrancart
Copy link
Contributor Author

Great. As agreed earlier I would however wait for this proposal to be published as it is now in "pending" (since the PR has been merged, etc.) and then move on to a second round of modifications improvements, including this one.

@ghost
Copy link

ghost commented Jul 12, 2017 via email

This was referenced Sep 7, 2017
Open
Closed
@danbri
Copy link
Contributor

danbri commented Sep 12, 2017

Looping back...

This work went out as part of v3.3 recently:

http://schema.org/docs/releases.html#v3.3

Thanks again to everyone for their work on this. While it is staged in pending.schema.org the vocabulary can be used, we'll just park it there for a while to get implementation feedback, with particular focus on integration into schema.org. If there is interest we could move it towards a named extension like "legal" with other related efforts, or simply into the core.

Meanwhile someone was independently suggesting "isBasisFor". I remembered that was also proposed here but I don't see it any more... @tfrancart can you remind me what happened?

@ppKrauss
Copy link

oops, @danbri if the target for publication of v3.3 was 2017 (is it?), see 2018 (2018-08-14) at http://schema.org/docs/releases.html#v3.3

@danbri
Copy link
Contributor

danbri commented Sep 12, 2017

Thanks - will fix to 2017

@tfrancart tfrancart mentioned this issue Sep 20, 2017
Closed
@tfrancart
Copy link
Contributor Author

Now that this has been released to pending, I am closing this issue and I create a new one for further discussions and comments : #1743

@rtroncy rtroncy mentioned this issue Jun 19, 2018
Closed
danbri added a commit that referenced this issue Apr 14, 2020
@danbri
Updated to use a new /jurisdiction property, and relate it
e054e61 
as a superproperty to legislationJurisdiction from the
Legislation work, /cc #1156.

Foor #2534
@ppKrauss
Copy link

About https://schema.org/legislationType where "statutory instrument" is one of the examples, are there any plans to use Legislation or similar to assign official non-governmental statutes?

For example the main content of https://prev.openstreetmap.fr/statuts is not a French government document (the author is not .gouv.fr authority), but is a legal "statutory instrument" of a French collective, provided for in French law.

@tfrancart
Copy link
Contributor Author

About https://schema.org/legislationType where "statutory instrument" is one of the examples, are there any plans to use Legislation or similar to assign official non-governmental statutes?

No. "Statutory instrument" is a kind of delegated legislation in UK and other countries. Legislation type is here to describe the acts that make the "legislation corpus" of a country/jurisdiction and that are published in an Official Journal.

I guess another type would be needed to markup such legal documents.

@ppKrauss
Copy link

Thanks @tfrancart, good explanation and quick response!

I guess another type would be needed to markup such legal documents.

Another legislationType only, or also another kind of CreativeWork for "non-governmental statutes"?

If it is only to add a new key-word for legislationType, can we suggest here a new one?

If official documents of NGOs (imagine for example official acts of a Condominium or a Foundation) are not Legislation... Can you suggest a kind of CreativeWork (e.g. DigitalDocument seems reasonable despite being limited to digital media), or a draft or pending vocabulary which is a better choice for the "non-governmental statutes"?

PS: maybe all pending classes of this context are waiting the most general Contract class (or "Accord" or "LegalTransaction").

@tfrancart
Copy link
Contributor Author

Another legislationType only, or also another kind of CreativeWork for "non-governmental statutes"?

Another kind of CreativeWork for xxxxxx statutes.

I don't have a suggestion of an existing type, my feeling is that SDO is missing what you need. Contract, LegalDocument, LegalNotice are the types that come to my mind.

@HughP
Copy link

HughP commented Apr 16, 2020 •
edited

@tfrancart @ppKrauss are you talking about something which might be called in USA parlance "articles of incorporation" (https://en.wikipedia.org/wiki/Articles_of_incorporation) or "by laws" (https://en.wikipedia.org/wiki/By-law)?

@ppKrauss
Copy link

@HughP the typical case (and in my example the "non-governmental statute" for Brazil, France etc.) is By-law... But a generalization is also necessary, so articles of incorporation, Brazilian Foundation Statute, Brazilian Consominium Convention, etc. (each country with some specialization) need similar document, perhaps the same general CreativeWork sub-class for it.

@tfrancart tfrancart mentioned this issue Sep 8, 2020
Open
@SQPEQUENA
Copy link

Update : see extension v3 below (09 november 2016)

A proposed extension to describe Legislation within schema.org has been published at http://legal.eli-legislation-schemaorg.appspot.com/Legislation. Additional material and use-cases description can be found on the extension page (examples still needed). The proposal was announced on the mailing-list.

The extension includes the following classes and enumerations :

  • Legislation (subclass of CreativeWork) "A legal act or a component of a legal act (like an article).", with 24 new properties.
  • LegislationObject (subclass of Legislation and MediaObject) "A specific object or file containing a Legislation. Note that the same Legislation can be published in multiple files. For example, a digitally signed PDF, a plain PDF and an HTML version."
  • LegalValueLevel "A list of possible levels for the legal validity of a legislation."
  • LegalForceStatus "A list of possible statuses for the legal force of a legislation."

The diagram below gives an outline of the extension :

schemaorg-diagram-only-v8

This extension proposal comes with suggestions to improve the core schema :

This extension is adapted from the European Legislation Identifier (ELI) ontology. The ELI development is driven by national legal publishers of some European countries, and by European institutions, all aiming at identifying, describing and linking legislation on the web. For more information on ELI, see the ELI register.

We would love to get feedback from the community on this proposal to improve the description of legislation with schema.org. Our objective is that this proposal be integrated either as a hosted extension, or even in the core.

``

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
schema.org vocab General top level tag for issues on the vocabulary status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests