There was also the topic of courts, see #1156 (comment) ... I could make a pass at coding up that proposal in RDFS if there's consensus that it could be a good fit. But it hasn't had the level of review that went into the earlier Legislation schemas.

@tfrancart This new property just landed in Wikidata...

Number of Constituencies
'number of constituencies related to a legislative body'
https://www.wikidata.org/wiki/Property:P4253

Useful somewhere in the extension ?

Hi all,

I am pleased to announce that luxembourg’s Official journal has implemented schema.org/legislation for all the acts published in 2017. All the other acts will follow shortl.

have look at www.legilux.public.lu

Or for one single act

https://search.google.com/structured-data/testing-tool#url=http%3A%2F%2Flegilux.public.lu%2Feli%2Fetat%2Fleg%2Floi%2F2017%2F08%2F29%2Fa789%2Fjo

Hey @johndann - that is fantastic news!

Do you have any implementor's feedback on the current specs + examples, based on your experience?

Thanks, that's great. Any other official sources of the markup bubbling under here?

Also - are there any efforts related to the ELI schemas but more on the processes around creation of new laws, bills, amendments and so on, i.e. with an element of civic engagement rather than laws being pre-agreed fixtures? I know there have been some efforts in the UK around Parliament (/cc @fantasticlife), but I'm not aware of anything international...

Most of our recent efforts have been around modelling parliamentary procedure. There's a small model here:
https://ukparliament.github.io/ontologies/procedure/procedure-ontology.html
which is really more of a lightweight process model than a procedure model.
The examples section shows various types of secondary legislation procedure in the UK Parliament.
Very interested in chatting to other people who might be looking at similar...

Thanks @fantasticlife !

@tfrancart - do you have anything? I'm interested here in augmenting the current model to talk about legislation-being-prepared, as much as possible in a general way (all countries, national-international-regional, etc.). For example, if we added a property (advocate/proposer; maybe subproperties for primary vs secondary?) to say who is pushing some proposal, ... that seems useful to have, but perhaps not the kind of information that the publishers of the eventual legislation would have.

Actually yes, extending ELI to "draft legislation" is our current task. And we are preparing a model for it. (Note that this model is only interested in identifying the documents and events happening during a legislative process, so it is not covering the entire parliament works like debates recording, etc. and is not trying to be a process model).

I definitely would be interested to align with @fantasticlife, I need to see if your draft work can be considered mature enough to be shared. In the meantime I can share pointers to the various webpages of different EU countries websites that could be annotated with the extension we are preparing (in no particular order) :

• Ireland : https://www.oireachtas.ie/en/bills/bill/2017/108/
• Portugal : https://www.parlamento.pt/ActividadeParlamentar/Paginas/DetalheIniciativa.aspx?BID=6337
• France : Assemblée Nationale : http://www.assemblee-nationale.fr/dyn/15/dossiers/retablissement_confiance_action_publique#confiance_action_publique Sénat : https://www.senat.fr/dossier-legislatif/pjl16-581.html Official Journal : https://www.legifrance.gouv.fr/affichLoiPubliee.do;jsessionid=AAC8DA9F9E12E93A3B6D081C77950BF3.tplgfr36s_2?idDocument=JORFDOLE000034924758&type=general&legislature=15
• Luxembourg : http://legilux.public.lu/eli/etat/proj/pl/20170206
• EU : https://eur-lex.europa.eu/procedure/FR/199041?qid=1511468404029&rid=111

Hi guys,

I work in the Federal Senate of Brazil and I am proud to announce that we have implemented schema.org for a subset (15,000) of the legal acts passed by the Brazilian Federal Parliament since 1822 (when Brazil became an independent country).

In this weekend, we will generate the remainder (around 200,000). After that, any new legal act passed by the Brazilian Federal Parliament will automatically be implemented with schema.org.

Some examples:
https://search.google.com/structured-data/testing-tool/u/0/#url=http%3A%2F%2Fwww.lexml.gov.br%2Furn%2Furn%3Alex%3Abr%3Afederal%3Alei%3A2006-08-07%3B11340
https://search.google.com/structured-data/testing-tool/u/0/#url=http%3A%2F%2Fwww.lexml.gov.br%2Furn%2Furn%3Alex%3Abr%3Afederal%3Alei.complementar%3A2006-12-14%3B123

There are some doubts and suggestions about “legislation” that I will be presenting in the next posts.

Hi @johndann .

Firstly, I would like to congratulate everyone for the excellent work on "legislation" and thank the support offered. We are very excited about the possibilities opened up by this movement.

The Brazilian Senate has a historical basis with a lot of structured information about the Brazilian laws. In this way, it is possible to regenerate the pages of the laws with new JSON definitions when necessary.

So we are already planning new milestones for upgrades:

• We will try to to implement schema.org on the pages of the articles of the laws (and their subdivisions) using the "isPartOf" property to formalize "whole-part" relationships.

• We would like to define structured value for the property "about" in each law that contains Organization, Person, Locality etc referenced by it -- would it be better to use property "mentions"?

There are situations in which the law, in addition to making reference to an Organization, also creates this organization (for example, a Government Institution) or closes that organization, from a date (beginning of validity of the action). However, we have not yet identified the best schema.org element to structure this situation. Do you have any suggestion?

Thanks
Hudson

Senado Federal do Brasil
email: [email protected]

Hello

We will try to to implement schema.org on the pages of the articles of the laws (and their subdivisions) using the "isPartOf" property to formalize "whole-part" relationships.

This is the way to go. The Legislation type, as per its definition, can be used to type subdivisions of a legal document.

We would like to define structured value for the property "about" in each law that contains Organization, Person, Locality etc referenced by it -- would it be better to use property "mentions"?

I would tend to use "mentions", as "about" could be kept for the main subject of the law (typically in the case law is indexed on a thesaurus), versus the entities mentionned in the content. Note that you can use legislationJurisdiction to indicate the administrative area from which the legislation orginates, and spatialCoverage to indicate the area on which the legislation applies.

There are situations in which the law, in addition to making reference to an Organization, also creates this organization (for example, a Government Institution) or closes that organization, from a date (beginning of validity of the action). However, we have not yet identified the best schema.org element to structure this situation. Do you have any suggestion?

You are raising a good point, and I think this is related to #1786 to introduce a new type PublicOrganization; by definition, they would be the kind of Organizations impacted by the changes you describe.
A suggestion on top of my head would be to use the CreateAction type, maybe; something like :

# the law
br:law123 a schem:Legislation .
br:law123 schema:name "Law that introduces a new organization Foo" .

# the organization
br:orgFoo a schema:Organization .
br:orgFoo schema:name "Foo" .
# or br:orgFoo a schema:PublicOrganization .

# the Action that connects the Legislation and the Organization
br:actionABC a schema:CreateAction .
# date of creation
br:actionABC schema:startTime "2018-09-01" .
# organization being created/modified/destroyed - could be also schema:result
br;actionABC schema:object br:orgFoo .
# link from the action to the Legislation - not really sure schema:instrument is the best option
br:actionABC schema:instrument br:law123 .
# agent creating the organization
br:actionABC schema:agent br:MinistryX (or GovernementX) .
br:MinistryX a schema:Organization .

Which basically reads "MinistryX created organization Foo with the Legislation 123 on the 2018-09-01"

Hi John,

It is good to know that the ELI project is already achieving a significant number of accessions by the member countries of Europe and that it is open for accession by non-European countries.

In parallel to schema.org, we will try to better understand the ELI proposal and evaluate the possibility of an integration.

Hudson

Hi @tfrancart

"about" could be kept for the main subject of the law (typically in the case law is indexed on a thesaurus), versus the entities mentionned in the content.

We are using ''keywords" property to inform the list of thesaurus terms associated with the law. Is it better to use "about " list in this case?

Note that you can use legislationJurisdiction to indicate the administrative area from which the legislation orginates, and spatialCoverage to indicate the area on which the legislation applies.

We are already using the "LegislationJuridiction". We will then add the "spatialCoverage".

You are raising a good point, and I think this is related to #1786 to introduce a new type PublicOrganization; by definition, they would be the kind of Organizations impacted by the changes you describe. A suggestion on top of my head would be to use the CreateAction type, maybe; something like...

Very interesting your suggestion. We will do some testing to verify this possibility.

Thanks
Hudson

Umm, No. Rabbit holes are deeper here. Let me help out.,.

Techinically, Laws don't do anything themselves :-) They ALLOW or DISALLOW actions by people/organizations. A Law ALLOWS the creation of an Organization to happen. The reality is that Who/What creates an Organization is often a single leader or head of that organization who gathers people or hires them into that organization and gives them jobs and roles.

• If you care about accuracy and want to capture WHAT/WHO created an Organization that will sometimes be very difficult to even find out most of the time,
• If you want to capture WHAT ALLOWED CREATION OF AN ORGANIZATION, then I'd suggest a property like "allowedCreationOf" and the inverse "creationOfAllowedBy"

Ah just saw @tfrancart use of CreateAction , yes that could work, but as I said, for accuracy, you often will not ever find out who the actual Creation Agent is, but only know the Instrument (law).

@thadguidry we are talking about public services or administrative authorities. I am not a lawyer, but it seems to me these organizations are indeed created by the virtue of laws passed by parliaments or local authorities, (at least in France : https://fr.wikipedia.org/wiki/Droit_du_service_public_en_France#Cr%C3%A9ation,_suppression_et_organisation_des_services_publics). The law does not allow a new service to exists, it effectively creates a new service. Here is an example from France : https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000625158#LEGIARTI000006758964

Translation : "The preliminary book of the fourth part of the Public Health Code is repealed from a date fixed by decree of the Conseil d'Etat and no later than 1 January 2005. From that date, the High Authority of Health succeeds to the French Agency for Health Security of Health Products in its rights and obligations under the fund for the promotion of medical and medico-economic information."

(note that in this case, a previous organization is dissolved, a new one is created)

@tfrancart You are not understanding. Let me explain further...

There is a difference between ..

• creating a legal entity (what you are talking about)
• creating an entity (what I am talking about)

I guess this issue #1743 is only discussing about legal entities? And that's fine, but let's come to agreement then that this issue is a very narrow scope within Schema.org and is in fact only discussing "legal" entities.

If so, then I'd suggest a property like "createdLegalEntity" , etc.

I guess this issue #1743 is only discussing about legal entities?

Yes

let's come to agreement then that this issue is a very narrow scope within Schema.org

Yes, this is what schema.org extensions are for.

and is in fact only discussing "legal" entities.

Yes

If so, then I'd suggest a property like "createdLegalEntity" , etc.

Then we would need "dissolveLegalEntity" and "modifiedLegalEntity"; maybe a single-property approach is too limited; exploring what Actions or Event could do (as does ChangeEvent in the ORG ontology) seems like a more flexible approach and would maybe not require any modification to the vocabulary.

Hi @tfrancart

We evaluate the use of CreateAction, as you suggested, to represent the creation of legal entities by law and we think it is appropriate.

I saw that there is UpdateAction, which could be used to represent changes in legal entities by law (for example, a change in the delimitation of a national park).

I did not find an Action to represent the closure, dissolution of a legal entity. Would you know the best way to represent this situation?

UpdateAction has the subclass DeleteAction. Would that fit ?
There is UpdateAction, too.

DeleteAction was an evaluated option. However, the description (The act of editing the recipient by removing one of its objects) left us doubts about its use in the context of the closure of an entity.

It looks more like removing an item from another. We would have to give an interpretation for closure / dissolution as a withdrawal of the entity from the set of public institutions of the country, for example.

Therefore, the ideal term would be something like TerminativeAction or ExtinctionAction. But, in the absence of another Action, we will evaluate the possibility of using DeleteAction.

Hello

I am pleased to announce that 130,000 legal acts passed by the Federal Parliament of Brazil since 1822 are now implementing schema.org -- we are working to make the remaining 80,000 legal acts available soon.

And , in parallel, we are waiting for Google Search to present them in the knowledge graph....

Hi @tfrancart

We implement the properties that inform the dates of signing and publication of the laws, but we do not find a property to inform the beginning of validity of the law (or its part).

I've seen that the ELI project provides a property for this: "first_date_entry_in_force". Is there any reason for not having this possibility in schema.org? Or is there a property in "legislation" (or in the supertypes) that can be used for this purpose?

In Brazil, by default, the end of a law (or its part) is the beginning of validity of another law (or its part) that repeals the first. However, exceptionally, a temporary law may define its own end of validity. In this case, it would be necessary an optional end-of-period property to contemplate this situation. I have seen in the ELI project that there is the property "date_no_longer_in_forc". Is there any corresponding property in schema.org?

In Brazil, there is also the situation of reinvigoration of one law by another. A new law reactivates another that has been revoked previously. Thus, the new force of the reinvigorated law would be the beginning of validity of the new law (opens a new period of validity, not necessarily continuous in relation to the previous one). I think that the initial and final validity properties treated in the previous situations would also represent this last situation - but it would be necessary to treat typification of the relations between the laws, subject for another post.

Hi @johndann

After a long period preparing the basis for persisting the hierarchical structure of the content of laws, we are resuming the mapping of this base to schema.org.

We are thinking of using the "hasPart" property for this and we are evaluating two possibilities:

1. Generate an independent web page, and your url, for each element of the hierarchy of the law, such as chapters, articles, subsections, etc. Each page will have its own JSON-LD, which will contain the property "isPartOf" with the url of the "parent" page in the structure (until it reaches the law).
2. Generate only the web page of the law, but its JSON-LD containing the entire hierarchy (chapters, articles, subsections, etc.), represented through the property "hasPart".

In the second option, is it possible to define all the elements "legislation" (can be hundreds or thousands) of the hierarchy of a law entirely in the JSON-LD of that law?

Is it necessary to regenerate the "legislationDate", "temporalCoverage", "legislationPassedBy", "spatialCoverage", "legislationJuridiction" properties in the "legislation" elements of the hierarchy (contained in the "hasPart" property)? Or only when their values ​​are different from the values ​​of the law?

I imagine that these "legislation" elements that make up the hierarchy of a law, in the property "hasPart" of the law, can also have their own "id" and eventually their own "url" (relative to the page of the law), correct?

Hello

Answers to these questions go beyond the schema.org vocabulary and are more about your data dissemination channels in general. I can however provide answers since we faced somewhat similar issued at OPEU:

We are thinking of using the "hasPart" property for this

Yes, this is the correct property to use.

and we are evaluating two possibilities:

1. Generate an independent web page, and your url, for each element of the hierarchy of the law, such as chapters, articles, subsections, etc. Each page will have its own JSON-LD, which will contain the property "isPartOf" with the url of the "parent" page in the structure (until it reaches the law).

2. Generate only the web page of the law, but its JSON-LD containing the entire hierarchy (chapters, articles, subsections, etc.), represented through the property "hasPart".

You can do both because they adress 2 different use-cases :

1. Human use-case : I want to navigate to a specific subdivision of the law, and I want to read it in context. This is your option 2 : only the web page of the law, but each subdivision has an id/anchor in the HTML, allowing to create links to that specific anchor; and in that case it is sensible to describe all the hierarchy of subdivisions in the JSON-LD. However I don't know (and no one knows) whether any data consumer (including search engines) will make use of this:
2. Machine use-case : if you want to enable automated reuse of independant pieces of content of the laws (e.g. for side by side display of some articles, etc.) you need to provide an independant "page" that returns the raw HTML of only a subdivision (with JSON-LD inside); in this case this is only raw HTML, not made to display nicely in your portal, but made for external reuse; this is your option 1;

What we aim to do, and this is the trick, is that the same ELI subdivision URI can give access to both representations based on HTTP headers. e.g. http://....eli/dir/1980/181/art_2/par_3/oj (identifier for paragraph 3 of article 2 of directive xxx) can redirect to .../eli/dir/1980/181/oj#art_2.par_3 (anchor) or redirect to .../eli/dir/1980/181/oj/eng/html/art_2/par_3 (identifier for the content of paragraph 3 of article 2 in english and in HTML).

Is it necessary to regenerate the "legislationDate", "temporalCoverage", "legislationPassedBy", "spatialCoverage", "legislationJuridiction" properties in the "legislation" elements of the hierarchy (contained in the "hasPart" property)? Or only when their values ​​are different from the values ​​of the law?

This really depends on the level of intelligence we think the data consumers will have. Maybe the answer also depends on the solutions described above.

I imagine that these "legislation" elements that make up the hierarchy of a law, in the property "hasPart" of the law, can also have their own "id" and eventually their own "url" (relative to the page of the law), correct?

Yes, see answer above. This is actually the primary use-case : allow a human reader to navigate/create links to a given anchor within the full content (ha, we still consider human readers to be the primary use-case, before machines :-) )

HTH !

@tfrancart Couldn't help but notice you writing about a subdivision URI in ELI. Just a small hijack -- is that already in the works and soon to be implemented? Like, can we already access subdivisions or representations of articles (and their subdivisions) in some way either from the web or via CELLAR?

Curious, when you folks say "subdivisions", do you mean PARTs, TITLEs, Chapters, Sections, Paragraphs, Sub-paragraphs, Points -- all inclusive? And when you say "sections", do you also include those parts, titles and chapters? ;)

Another issue I've found from my own reviews is that it doesn't stop at Points. An article "content" hierarchy or "inner subdivision" can look like this:

• Paragraph
  • Sub-paragraph
    • Point
      • (Sub-?)Point
        • (Sub-sub-?)Point

I find it odd to have a URI fragment for these encoded with a static literal such as "par_n" or "point_n" because when does it end? If there is a markup effort for this here, I'd suggest something that facilitates the scheme "art3.1.3.2". At a level above that, navigating sections/subdivisions could be "subdiv1.2.3". This would allow granular representations and decomposition, rather than stopping at the first Paragraph level.

@johndann @hmartim From my experience and experiments I can attest to the isPartOf traversal being very useful and common in navigating a regulatory document. However, with such a broad transitive property transitive reduction is also necessary, for e.g. via a regular isArticleOf or isClauseOf subproperty.

Hello @schivmeister ; I suggest you read https://eur-lex.europa.eu/eli-register/eu_publications_office.html where subdivision identification for EU legislation is documented and where you will find the contact email to send these questions. You can also open a discussion on https://joinup.ec.europa.eu/collection/eli-european-legislation-identifier. Nevertheless here are some answers:

when you folks say "subdivisions", do you mean PARTs, TITLEs, Chapters, Sections, Paragraphs, Sub-paragraphs, Points -- all inclusive?

In my mouth, yes, when I say "subdivisions", I mean all of these, and more.

I find it odd to have a URI fragment for these encoded with a static literal such as "par_n" or "point_n" because when does it end?

It ends where the content structure ends. The literal id is not just "point_n", it is "art_x.par_y.pnt_z.pnt_a", depending on the content structure.

If there is a markup effort for this here, I'd suggest something that facilitates the scheme "art3.1.3.2"

See previous answer.

This would allow granular representations and decomposition, rather than stopping at the first Paragraph level.

Concerning EU legislation we are not stopping at the first paragraph level, but aim at identifying every possible subdivision of an act, up to e.g. a specific cell in an annex table. Others may choose to implement it differently.

I suggest to continue the discussion in one of the communication channel indicated above.

Hi @johndann

This week, an IPU (Inter Parliamentary Union) meeting is taking place in Brazil, with representatives from several parliaments of the world, such as Spain, Estonia, Finland, Israel, Canada, Ukraine, South Africa, Chile, the European Parliament, among others.

The focus of the meeting is technology and one of the tasks is to define a metadata vocabulary for bills. I suggested using schema.org/Legislation and commented that this schema is based on the ELI project and is already implemented in acts in Luxembourg and Brazil.

One important information to help support my suggestion would be: how many and which European countries are already implementing, besides ELI, or planning to implement schema.org/Legislation in their acts?

Could you provide me with this information so that I can disclose it at the event?

Thanks.

I can only emphasize that schema.org/Legislation is not (and was not meant to be) a good starting point to describe bills / draft legislation. You should definitely have a look at ELI-DL, starting with the diagrams at https://joinup.ec.europa.eu/solution/eli-ontology-draft-legislation-eli-dl/distribution/eli-dl-examples-and-diagrams. This is currently open for comments and a final version will be released end of 2019.
Cheers

So schema.org won't have a solution for bills implementation in the short or medium term?

I am not referring to the legislative process... but only to the proposition document.

Describing only the proposition document misses the point, since web pages that describe bills do not only give access to the proposition document but also describes : the steps/workflow of the bill (timeline), the amendments, the related documents, the legal basis of the legislative project, the commitee meetings, etc. See e.g. https://eur-lex.europa.eu/legal-content/EN/HIS/?uri=CELEX:52018PC0218&qid=1559132591318 or http://www.senat.fr/dossier-legislatif/pjl18-084.html
Any serious proposal for a semantic markup of bills should allow to describe these information.
It is not impossible that, once ELI-DL is stable and starts being implemented, we propose it as an extension to SDO, just like what happened with ELI.

The vision of a bill under a complete project/process perspective is actually the most appropriate to be used by a parliament, such as the Federal Senate of Brazil.

But the goal of the IPU is to create a simplified global dataset (and hub and portal) that allows a comparative analysis of the textual content, and some metadata, of the legislation (acts and bills) of different countries on the same subject. In this case, a document perspective (such as that described in schema.org/legislation: "A legal document such as an act, decree, bill, etc ...") may be sufficient - and simplifies the integration of any parliament as a source of legislation. In any case, more technical decisions (choice of vocabulary, choice of formats) were postponed to subsequent remote meetings, probably.

Thanks.

@tfrancart , in relation to ELI, some questions:

• is it a restricted standard for EU members, and guests, or is it an open standard for any country, such as schema.org/legislation?
• Countries that have a different structure for the formation of the URI (case of Brazil) are able to represent their laws using ELI?
• Does ELI accept the JSON-LD format?
• Could you share examples of some laws in json, or rdf format?
• If you have those same examples represented also in schema.org/legislation, it would further facilitate a quick survey of generation complexity in ELI format ...

Thanks

is ELI a restricted standard for EU members, and guests, or is it an open standard for any country, such as schema.org/legislation?

It is indeed a standard open for any country to implement, and all the documentation for that is available. The ELI Taskforce driving the project however meets in the framework of EU institutions.

Countries that have a different structure for the formation of the URI (case of Brazil) are able to represent their laws using ELI?

Yes, the URI pattern and the metadata model are decoupled.

Does ELI accept the JSON-LD format?

Yes, in its latest version.

Could you share examples of some laws in json, or rdf format?

You can look at RDFa header in a random page from Luxembourg : http://legilux.public.lu/eli/etat/leg/rmin/2019/05/27/a368/jo, Ireland : http://www.irishstatutebook.ie/eli/2017/act/5/enacted/en/html. Finland uses JSON-LD but in its own extension of ELI : https://data.finlex.fi/eli/sd/2008/521.html (so this could be confusing for you).

If you have those same examples represented also in schema.org/legislation, it would further facilitate a quick survey of generation complexity in ELI format ...

Well, we actually have it the other way around : a converter from ELI to SDO : http://publications.europa.eu/eli-validator/eli2sdo which is based on a formal mapping between the 2 models : http://publications.europa.eu/eli-validator/eli-sdo/eli-sdo.ttl

A useful resource I think you can look at is the ELI technical guide : https://publications.europa.eu/en/publication-detail/-/publication/8159b75d-5efc-11e8-ab9c-01aa75ed71a1

Hi @tfrancart ,

I did some preliminary testing with a possible JSON format of the ELI project. Are attached.

Could you pass them on to someone to validate them and identify any tweaks, or point me to some automatic JSON validation ELI tool?

leiTeste_ELIJson.txt
leiTeste2_ELIJson.txt

Hi @tfrancart ,

To try to facilitate the following of the examples I presented earlier, I have attached 2 laws with their metadata in Schema.org/Legilation/Json, ELI/Json and ELI/Rdf. Like a "Rosetta Stone"...

Thanks.

LeiTeste_MultiSchema.txt
leiTeste2_MultiSchema.txt

Hi @johndann

Do you know if @tfrancart is still acting in this discussion group?

We are evaluating the possibility of generating the formats (rdf or json) of the ELI project. We did some tests, presented in the two previous posts.

If Thomas is no longer in the group, could you pass these 2 posts to an ELI technician so he could help us finish our attempts?

Thanks

Hello

Could you pass them on to someone to validate them and identify any tweaks, or point me to some automatic JSON validation ELI tool?

Warning, this is JSON-LD we are talking about, not plain JSON.

You could use the ELI validator at http://publications.europa.eu/eli-validator/validate and embed your JSON-LD in a simple HTML file, and send the HTML file to the validator. This is the technique I used for the file provided below.

Don't forget that to be ELI compliant the first step is not to disseminate the metadata, but to specify an ELI URI pattern, similar to all the patterns described in the country-specific pages at https://eur-lex.europa.eu/eli-register/implementation.html.

Looking at leiTeste_ELIJson.txt I do have comments :

1. You must declare a context so that JSON key are properly interpreted as ELI properties. Don't forget this is JSON-LD, not plain JSON :

  "@context": {
    "@vocab": "http://data.europa.eu/eli/ontology#"
  },

And within the context you must declare as such all keys having a URI as a value (see modified file below), and you must assign an xsd:date to the date properties.

2. http://publications.europa.eu/legalResource/authority/language/POR should be http://publications.europa.eu/resource/authority/language/POR

3. #InForce-NotInForce must be #InForce-notInForce

4. .../application/html must be .../text/html

5. "passed_by": "https://pt.wikipedia.org/wiki/Congresso_Nacional_do_Brasil" and "type_document": "https://en.wikipedia.org/wiki/Ordinary_law" : you must define a controlled list you own for these 2 value sets, and not refer to Wikipedia.

6. There are no URIs for the format files, bur rather website specific URLs like http://legis.senado.leg.br/legislacao/ListaTextoSigen.action?norma=551193&id=16305908&idBinario=16371081&mime=application/rtf

Here is a modified version of leiTeste_ELIJson.txt, embedded in an HTML and modified to fix some errors listed above :
leiTeste_ELIJson.html.zip

Hello @johndann and @tfrancart

Describing only the proposition document misses the point, since web pages that describe bills do not only give access to the proposition document but also describes : the steps/workflow of the bill (timeline), the amendments, the related documents, the legal basis of the legislative project, the commitee meetings, etc. See e.g. https://eur-lex.europa.eu/legal-content/EN/HIS/?uri=CELEX:52018PC0218&qid=1559132591318 or http://www.senat.fr/dossier-legislatif/pjl18-084.html
Any serious proposal for a semantic markup of bills should allow to describe these information.
It is not impossible that, once ELI-DL is stable and starts being implemented, we propose it as an extension to SDO, just like what happened with ELI.

Is there already a forecast for this SDO proposal?

As long as there is no such extension, is there any property in schema.org/legislation to inform the associated bill?

Cheers.

Hi, There are at least 3 countries are looking in the DL using ELI. Luxembourg, Switzerland and Poland, and various steps of implementation. The easy way would actually to implement ELI fully at your level and then create schema.org Extension metadata from this ELI data. The first ELI-DL is scheduled to be released in a couple month (not under schema.org/legislation for the moment) , for the moment it is still under BETA. Thomas can provide you with more details if needed. What do you think about this ? John

We were experimenting with ELI's JSON-LD, but we couldn't evolve because the id of each law must follow the ELI uri pattern.

In Brazil, we have been using an id based on the Lexml urn for two decades.

The implementation of schema.org was feasible because it has a free id formation.

We got it right, or is there a way to implement ELI using id free formatting?

Hudson.

Hello

I believe I'm coming into this rather late and might not be in possession of all the facts. On:

Describing only the proposition document misses the point, since web pages that describe bills do not only give access to the proposition document but also describes : the steps/workflow of the bill (timeline), the amendments, the related documents, the legal basis of the legislative project, the committee meetings

These feel like different problems perhaps? At UK Parliament we're moving toward a bill > Act drafting and amending tool based on Akoma Ntoso. I'm afraid I don't know enough about how well that is mapped to ELI.

But that is still document rather than process based. We also have a procedure model:
https://ukparliament.github.io/ontologies/procedure/procedure-ontology.html

which is actually a general purpose process flow model instantiated with data to map a given parliamentary procedure such as public bill procedure:
https://ukparliament.github.io/ontologies/procedure/flowcharts/bills/public-bill.pdf

(^ work in progress)

Obviously what happens in the procedure model is the engine of state for document changes and the two need to be closely coupled. But they feel quite different to me...

michael

@fantasticlife : ELI-DL at https://joinup.ec.europa.eu/solution/eli-ontology-draft-legislation-eli-dl/distribution/eli-dl-examples-and-diagrams is exactly trying to articulate an event-based model (LegalActivities) with a document-based model (taking FRBRoo as an inspiration), to describe the successive versions of a drafted act and its related document.
This is in the spirit of the UK parliament procedure ontology.

We got it right, or is there a way to implement ELI using id free formatting?

Hello Hudson, as this (very interesting) question is more related to ELI than to schema.org, you can get in touch directly at thomas dot francart at sparna dot fr and John dot Dann at scl dot etat dot lu. I think it deserves to be escalated to the ELI taskforce, it will be interesting to have a dedicated discussion channel for it, and I will forward this question (and others you may have) to the taskforce members.

But, to give you an (unofficial) answer : as long as your identification mechanism enables you to identify all the entities of the ELI model (LegalResource, LegalExpression, Format), go ahead and use the ELI ontology, even if your identifiers don't look like ELIs.

Faced with that possibility, we will resume the tests soon.

Thanks Thomas.

As the refinements announced in the initial comment of this thread have been implemented, and as we are considering future contribution to the Legislation type, I will close this issue and open a new one.