-
Notifications
You must be signed in to change notification settings - Fork 825
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.
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
Legislation : Proposed extension #1156
Comments
Thanks for the comprehensive proposal! One of the best documented we've received :) |
Thanks, we hope this can make it through to become a hosted extension, then ! |
Hi Thomas, Hi Dan, |
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? |
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. |
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, |
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. 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, |
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) |
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 :
Cheers |
Ha, and by the way, I have also added 2 markup examples to http://legal.eli-legislation-schemaorg.appspot.com/Legislation. |
Hi @tfrancart;
etc. |
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 :
Should I try to be as precise as possible in the naming of every properties to avoid any potential name clashes ? |
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) |
@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:
|
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 |
@tfrancart @RichardWallis @danbri @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 @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 |
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. |
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 |
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 :
|
Hyperlinks are now included in the definitions. |
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. |
Then let me note my +1 for the proposal :-) |
Hello Here is a proposal for renaming the properties to disambiguate them; basically prefixing everything with "legislation" :
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 |
@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. My 2cents, |
Our approach at schema.org is that we agree
But we'd express it different. Rather:
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
Markup showing 'birthPlace' written in reverse, i.e. starting with the Place.a) using @reverse at the point the property is needed
b) for the publisher of the markup to define their own inverse property
(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. |
Aside from the inverses question, @tfrancart can you comment on @johndann's remark about date applicability? i.e.
|
(After internal discussion with @johndann and @mwkuster) @danbri :
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.
Understandable. Agreed.
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. |
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. |
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? |
didn't appear to have jurisdiction? which is similar to:
https://github.com/schemaorg/schemaorg/issues/1662
the rest of the stuff there about legislation.... i note it says 'a legal
act', i also wonder about 'legal principle' --> I don't know enough liar
stuff to tell whether 'choice of law' is appropriately put into legislation
or whether it's a legalpolicy or legalPriniple (with reference,
jurisdiction et.al.).
…On Tue, 11 Jul 2017 at 02:56 f1234k ***@***.***> wrote:
Can we start using everything that is described here
<http://pending.webschemas.org/Legislation> in our websites? What is the
timeline of the adoption status in official schema.org definitions?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1156 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFdABqGUjwB_iP417uHPJjjeYEwIOo97ks5sMle6gaJpZM4Ib7Sw>
.
|
"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". |
ChoiceOfLaw denotes interpretation of claims and their explicit and
implicit meaning to users of those agreements.
Ie: federal privacy laws is different in different countries.
Tim.
…On Tue., 11 Jul. 2017, 5:42 pm Thomas Francart, ***@***.***> wrote:
"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".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1156 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFdABt_kfd8xiKzb-x0SJdu7nqba9Wooks5sMydjgaJpZM4Ib7Sw>
.
|
@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 |
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. |
Asap is always desirable. Noting also, I wasn't sure how schemaorg version
control worked?
…On Wed., 12 Jul. 2017, 5:33 pm Thomas Francart, ***@***.***> wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1156 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFdABg2s1RttxFq0a4Tl6WOtA_g4fmQVks5sNHatgaJpZM4Ib7Sw>
.
|
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? |
oops, @danbri if the target for publication of v3.3 was 2017 (is it?), see 2018 ( |
Thanks - will fix to 2017 |
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 |
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 |
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. |
Thanks @tfrancart, good explanation and quick response!
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"). |
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. |
@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)? |
@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. |
`` |
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 :
The diagram below gives an outline of the extension :
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.
The text was updated successfully, but these errors were encountered: