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

Closed
tfrancart opened this Issue May 11, 2016 · 88 comments

Comments

Projects
None yet
@tfrancart
Contributor

tfrancart commented May 11, 2016

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 :

  • #1154 Add "Legislation" as subclass of CreativeWork in the core schema
  • #1031 Create inverse property of schema:citation
  • #1153 Improve the definition of MediaObject
  • #1155 Improve the definition of encodingFormat
  • #1030 encodesCreativeWork should be made inverse of encoding
  • #1022 allow proper credits to properties and enumeration
  • #1151 broaden the range of property schema:version to allow Text
  • #1152 add a generic property "relatedTo" to relate CreativeWorks

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.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 11, 2016

Contributor

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

Contributor

danbri commented May 11, 2016

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

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart May 11, 2016

Contributor

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.

Contributor

tfrancart commented May 11, 2016

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.

@johndann

This comment has been minimized.

Show comment
Hide comment
@johndann

johndann May 31, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 3, 2016

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jun 6, 2016

Contributor

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.

Contributor

tfrancart commented Jun 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Jun 7, 2016

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,

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

This comment has been minimized.

Show comment
Hide comment
@johndann

johndann 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

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

This comment has been minimized.

Show comment
Hide comment
@mwkuster

mwkuster 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)

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

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jul 4, 2016

Contributor

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

Contributor

tfrancart commented Jul 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jul 4, 2016

Contributor

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

Contributor

tfrancart commented Jul 4, 2016

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

@twamarc

This comment has been minimized.

Show comment
Hide comment
@twamarc

twamarc Jul 4, 2016

Contributor

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

Contributor

twamarc commented Jul 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jul 4, 2016

Contributor

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 ?

Contributor

tfrancart commented Jul 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@twamarc

twamarc Jul 4, 2016

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Jul 4, 2016

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:

  • basedOn - use isBasedOn
  • cites - why is it necessary to subtype citation?
  • legislationIdentifier might be worth reviewing about general identifier issues (#428)
Contributor

RichardWallis commented Jul 4, 2016

@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:

  • basedOn - use isBasedOn
  • cites - why is it necessary to subtype citation?
  • legislationIdentifier might be worth reviewing about general identifier issues (#428)
@GerryMatthews

This comment has been minimized.

Show comment
Hide comment
@GerryMatthews

GerryMatthews Jul 5, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Jul 5, 2016

@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

thadguidry commented Jul 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Jul 5, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@johndann

johndann 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 ...

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

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jul 6, 2016

Contributor

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);
Contributor

tfrancart commented Jul 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jul 6, 2016

Contributor

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.

Contributor

tfrancart commented Jul 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Jul 6, 2016

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.

Contributor

RichardWallis commented Jul 6, 2016

  • 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

This comment has been minimized.

Show comment
Hide comment
@mwkuster

mwkuster Jul 13, 2016

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

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

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Aug 24, 2016

Contributor

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

Contributor

tfrancart commented Aug 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@twamarc

twamarc Aug 24, 2016

Contributor

@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

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

@jpmckinney

This comment has been minimized.

Show comment
Hide comment
@jpmckinney

jpmckinney Aug 24, 2016

I don't know any examples of existing property names in Schema.org that follow the pattern classNamePropertyName, so I think this is a break with the patterns in Schema.org. Schema.org does seem to encourage reuse of terms that have the same semantics in different contexts. For example, dateEntryIntoForce and dateNoLongerInForce are the same as Schema.org's validFrom and validUntil, which are reused across many types. I'm in favor of more reuse. I don't see how legislationCitedBy could possibly have any different semantics than a more general citedBy; there are a lot more examples like this.

jpmckinney commented Aug 24, 2016

I don't know any examples of existing property names in Schema.org that follow the pattern classNamePropertyName, so I think this is a break with the patterns in Schema.org. Schema.org does seem to encourage reuse of terms that have the same semantics in different contexts. For example, dateEntryIntoForce and dateNoLongerInForce are the same as Schema.org's validFrom and validUntil, which are reused across many types. I'm in favor of more reuse. I don't see how legislationCitedBy could possibly have any different semantics than a more general citedBy; there are a lot more examples like this.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 24, 2016

Contributor

The truth is somewhere in the middle. We try to re-use terms wherever possible, but in the cases where something is quite specific to a situation we've often qualified the term's name to leave open possible similar properties for different situations. Recipe has a few, for example.

It is worth going through and identifying those which really are special to legislation, since consumers of schema.org data are generally more likely to implement against more general terms. Often during this process we have identified things in the general vocabulary which could be improved to make re-use easier...

Contributor

danbri commented Aug 24, 2016

The truth is somewhere in the middle. We try to re-use terms wherever possible, but in the cases where something is quite specific to a situation we've often qualified the term's name to leave open possible similar properties for different situations. Recipe has a few, for example.

It is worth going through and identifying those which really are special to legislation, since consumers of schema.org data are generally more likely to implement against more general terms. Often during this process we have identified things in the general vocabulary which could be improved to make re-use easier...

@jpmckinney

This comment has been minimized.

Show comment
Hide comment
@jpmckinney

jpmckinney Aug 24, 2016

@danbri I'm in favor of a more selective prefixing, and not simply prefixing everything with legislation for the sake of expediency (or whatever reason, including consistency within the same class, because consistency across classes is more valuable).

I also wonder if there could be more reuse of existing terms from popular vocabularies. For example, some ideas with Dublin Core:

  • legislationIdentifier -> identifier
  • dateLegislation -> date
  • cites -> references
  • citedBy -> isReferencedBy
  • relevantArea -> subject

Other possibilities from PROV-O:

  • basedOn -> wasDerivedFrom
  • basisFor -> hadDerivation

And from Schema.org (see CreativeWork for other possibilities):

  • legislationVersion -> version
  • dateEntryIntoForce -> validFrom
  • dateNoLongerInForce -> validUntil
  • relevantArea -> about
  • cites -> citation
  • legalForce -> status

This is not a comprehensive review.

jpmckinney commented Aug 24, 2016

@danbri I'm in favor of a more selective prefixing, and not simply prefixing everything with legislation for the sake of expediency (or whatever reason, including consistency within the same class, because consistency across classes is more valuable).

I also wonder if there could be more reuse of existing terms from popular vocabularies. For example, some ideas with Dublin Core:

  • legislationIdentifier -> identifier
  • dateLegislation -> date
  • cites -> references
  • citedBy -> isReferencedBy
  • relevantArea -> subject

Other possibilities from PROV-O:

  • basedOn -> wasDerivedFrom
  • basisFor -> hadDerivation

And from Schema.org (see CreativeWork for other possibilities):

  • legislationVersion -> version
  • dateEntryIntoForce -> validFrom
  • dateNoLongerInForce -> validUntil
  • relevantArea -> about
  • cites -> citation
  • legalForce -> status

This is not a comprehensive review.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 24, 2016

Contributor

For the DC/PROV etc vocabularies, let's focus more on mappings than on the actual names. We have enough naming convention baggage (e.g. 'about' instead of 'subject') of our own to try to align with, without trying to coordinate more widely. But we can and should collect mappings. There are already a few in the system:

$ scripts/rdfa2nt data/schema.rdfa |grep 'owl#equival' > mappings.txt

Contributor

danbri commented Aug 24, 2016

For the DC/PROV etc vocabularies, let's focus more on mappings than on the actual names. We have enough naming convention baggage (e.g. 'about' instead of 'subject') of our own to try to align with, without trying to coordinate more widely. But we can and should collect mappings. There are already a few in the system:

$ scripts/rdfa2nt data/schema.rdfa |grep 'owl#equival' > mappings.txt

@jpmckinney

This comment has been minimized.

Show comment
Hide comment
@jpmckinney

jpmckinney Aug 24, 2016

@danbri I'm fine with that. But if there's a property for which we don't have any baggage, we might try to avoid creating baggage. I think we should at least try to reuse terms from Schema.org where that makes sense.

@danbri I'm fine with that. But if there's a property for which we don't have any baggage, we might try to avoid creating baggage. I think we should at least try to reuse terms from Schema.org where that makes sense.

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Aug 25, 2016

Contributor

Hello

Thanks for all the answers. I am adressing each of them below.

@twamarc :

Although the terms legislationApplies , legislationPassedBy , legislationChanges and other based on verb-word like consolidates are not clear to me. Maybe they have use-cases in domain.

They do. This proposal comes from the official legal publishers of 7 countries + the European institutions, and all the terms in the proposal have use-cases.

What is the difference between legislationDateEntryIntoForce and legislationDate ?

You can refer to the definitions given at http://legal.eli-legislation-schemaorg.appspot.com/Legislation. legislationDate is when the text officially becomes "the law", usually by being signed or promulgated. legislationDateEntryIntoForce is when the legislation takes effect; to take an example in Luxembourg, a law is effective 4 days after it was officially published (unless the law says otherwise).

@jpmckinney :

I don't know any examples of existing property names in Schema.org that follow the pattern classNamePropertyName, so I think this is a break with the patterns in Schema.org.

I agree, but on the other side I understood we need to make sure the properties name are unique across extensions. I think this will necessarily lead to very specific property names.

For example, dateEntryIntoForce and dateNoLongerInForce are the same as Schema.org's validFrom and validUntil

Not quite. In legislation we deal with there are 2 different time spans : the notion of "in force" (= in effect), and the notion of "applicable" (= that needs to be taken into account). A legislation can be in force without being applicable. A legislation can be in force and can have different dates of applicabilities depending on various criterias (in UK, could be applicable for Wales and Scotland at different dates). The notion of applicability have been left out of scope of this proposed extension.
Although the notion is subtely different, we could very well declare these 2 properties as subproperties of validFrom and validUntil.

I'm in favor of more reuse. I don't see how legislationCitedBy could possibly have any different semantics than a more general citedBy

I agree for reuse (and we have mapped a lot of terms of the original ELI ontology directly on existing schema.org properties), as long as the semantic fits the use-case.
I would be more than happy to see some proposed terms integrated in the core. citedBy currently does not exist in the core, and this is why we kept it in the extension. We propose to add it in the core in #1031. This is actually one the previous comments from @RichardWallis that needs to be adressed.

@danbri :

It is worth going through and identifying those which really are special to legislation, since consumers of schema.org data are generally more likely to implement against more general terms. Often during this process we have identified things in the general vocabulary which could be improved to make re-use easier...

Agreed. We have already pinpointed the terms from ELI that exist in SDO, but maybe we missed some, maybe compromises can be found, or maybe terms from the extension can be taken in the core.
The core added values, and what is really specific to legislation are, in my opinion : 1/ dates in the legislation lifecycle 2/ links between legislation 3/ the notions of legalForce (of a legislation) and legalValue (of a file).

@jpmckinney

legislationIdentifier -> identifier
dateLegislation -> date
cites -> references
citedBy -> isReferencedBy
relevantArea -> subject

We're in the schema.org world here, not in the DC world. Anyway : the ELI ontology from which the proposed extension is derived is already aligned to DC. Specific subproperties were created because we can't just reuse the broad semantic of DC for precise statements about legislation. dateLegislation is indeed a special kind of date, but there are more dates in the legislative lifecycle that need to be recorded. We need specific properties and we can't just go with DC for the sake of expediency.

basedOn -> wasDerivedFrom
basisFor -> hadDerivation

Again, an item from @RichardWallis that I need to adress. The legislative notion here is not a notion of "derivation", but rather a notion "was made possible by". A law "is made possible by" the constitution, but is not "derived from" the constitution. Let aside this small semantic difference, we could use a "basedOn" property from SDO core, if it had an inverse "basisFor".

And from Schema.org (see CreativeWork for other possibilities):

We did look at the existing properties from CreativeWork before submitting the extension.

legislationVersion -> version

At the time the extension was proposed, version was a number only. Now that #1151 is done, yes, we can reuse the version property.

dateEntryIntoForce -> validFrom
dateNoLongerInForce -> validUntil

see previous answer.

relevantArea -> about

No. This is not an area that is the subject of the legislation, it is an area that is the jurisdiction from the which the legislation originates, or on which the legislation applies (semantic was kept broad on purpose). Legislations do have other keywords taken from thesauri that are expressed using the about property.

cites -> citation

could be, see previous answer

legalForce -> status

status is currently only in the healh-lifesci extension and is defined as "The status of the study (enumerated).". This is not reusable as it is defined right now, but could be, provided it is moved in the core and its definition broaden.

@danbri :

But we can and should collect mappings. There are already a few in the system:

Nice. Will use this to align with ELI.

Contributor

tfrancart commented Aug 25, 2016

Hello

Thanks for all the answers. I am adressing each of them below.

@twamarc :

Although the terms legislationApplies , legislationPassedBy , legislationChanges and other based on verb-word like consolidates are not clear to me. Maybe they have use-cases in domain.

They do. This proposal comes from the official legal publishers of 7 countries + the European institutions, and all the terms in the proposal have use-cases.

What is the difference between legislationDateEntryIntoForce and legislationDate ?

You can refer to the definitions given at http://legal.eli-legislation-schemaorg.appspot.com/Legislation. legislationDate is when the text officially becomes "the law", usually by being signed or promulgated. legislationDateEntryIntoForce is when the legislation takes effect; to take an example in Luxembourg, a law is effective 4 days after it was officially published (unless the law says otherwise).

@jpmckinney :

I don't know any examples of existing property names in Schema.org that follow the pattern classNamePropertyName, so I think this is a break with the patterns in Schema.org.

I agree, but on the other side I understood we need to make sure the properties name are unique across extensions. I think this will necessarily lead to very specific property names.

For example, dateEntryIntoForce and dateNoLongerInForce are the same as Schema.org's validFrom and validUntil

Not quite. In legislation we deal with there are 2 different time spans : the notion of "in force" (= in effect), and the notion of "applicable" (= that needs to be taken into account). A legislation can be in force without being applicable. A legislation can be in force and can have different dates of applicabilities depending on various criterias (in UK, could be applicable for Wales and Scotland at different dates). The notion of applicability have been left out of scope of this proposed extension.
Although the notion is subtely different, we could very well declare these 2 properties as subproperties of validFrom and validUntil.

I'm in favor of more reuse. I don't see how legislationCitedBy could possibly have any different semantics than a more general citedBy

I agree for reuse (and we have mapped a lot of terms of the original ELI ontology directly on existing schema.org properties), as long as the semantic fits the use-case.
I would be more than happy to see some proposed terms integrated in the core. citedBy currently does not exist in the core, and this is why we kept it in the extension. We propose to add it in the core in #1031. This is actually one the previous comments from @RichardWallis that needs to be adressed.

@danbri :

It is worth going through and identifying those which really are special to legislation, since consumers of schema.org data are generally more likely to implement against more general terms. Often during this process we have identified things in the general vocabulary which could be improved to make re-use easier...

Agreed. We have already pinpointed the terms from ELI that exist in SDO, but maybe we missed some, maybe compromises can be found, or maybe terms from the extension can be taken in the core.
The core added values, and what is really specific to legislation are, in my opinion : 1/ dates in the legislation lifecycle 2/ links between legislation 3/ the notions of legalForce (of a legislation) and legalValue (of a file).

@jpmckinney

legislationIdentifier -> identifier
dateLegislation -> date
cites -> references
citedBy -> isReferencedBy
relevantArea -> subject

We're in the schema.org world here, not in the DC world. Anyway : the ELI ontology from which the proposed extension is derived is already aligned to DC. Specific subproperties were created because we can't just reuse the broad semantic of DC for precise statements about legislation. dateLegislation is indeed a special kind of date, but there are more dates in the legislative lifecycle that need to be recorded. We need specific properties and we can't just go with DC for the sake of expediency.

basedOn -> wasDerivedFrom
basisFor -> hadDerivation

Again, an item from @RichardWallis that I need to adress. The legislative notion here is not a notion of "derivation", but rather a notion "was made possible by". A law "is made possible by" the constitution, but is not "derived from" the constitution. Let aside this small semantic difference, we could use a "basedOn" property from SDO core, if it had an inverse "basisFor".

And from Schema.org (see CreativeWork for other possibilities):

We did look at the existing properties from CreativeWork before submitting the extension.

legislationVersion -> version

At the time the extension was proposed, version was a number only. Now that #1151 is done, yes, we can reuse the version property.

dateEntryIntoForce -> validFrom
dateNoLongerInForce -> validUntil

see previous answer.

relevantArea -> about

No. This is not an area that is the subject of the legislation, it is an area that is the jurisdiction from the which the legislation originates, or on which the legislation applies (semantic was kept broad on purpose). Legislations do have other keywords taken from thesauri that are expressed using the about property.

cites -> citation

could be, see previous answer

legalForce -> status

status is currently only in the healh-lifesci extension and is defined as "The status of the study (enumerated).". This is not reusable as it is defined right now, but could be, provided it is moved in the core and its definition broaden.

@danbri :

But we can and should collect mappings. There are already a few in the system:

Nice. Will use this to align with ELI.

@ppKrauss

This comment has been minimized.

Show comment
Hide comment
@ppKrauss

ppKrauss Sep 13, 2016

Remembering some general aspects that need some harmonization:

  1. There are a lot of popular (scholar and technical) "semanctic works" about US legislation, and little for other nations, that can create some distortion here... For instance, the US judiciary documents have different meaning and organization, than usual judiciary of civil law nations.

    1.1. The civil law nations must to use government official gazette to publish all its legal documents... So "legal documents" here are very close to the SchemaOrgs's core Article, because each content of a journal is an article.

    1.2. Oficial archives, as LexML-BR (with 1,238,121 legislative itens and 5,471,221 precedent itens), have good collections to check semantic distions on legislative/jurisdictional documents.

  2. Document (unique) persistent identification is a basic/fundamental issue. We need a property like DOI, but there are no "universal standard" as DOI for legislation, the best that exist is a national (local) standard and persistent "ID resolver" to redirect ID to document (as dx.doi.org do)...
    The best concept is URN (DOI meets the concept of URN), and there are a "legal URN", is the URN LEX. So, for SchemaOrg users, what we need is a "URN-Resolver URL" property.

  3. Document structure, as commented here, is another important issue.

Remembering some general aspects that need some harmonization:

  1. There are a lot of popular (scholar and technical) "semanctic works" about US legislation, and little for other nations, that can create some distortion here... For instance, the US judiciary documents have different meaning and organization, than usual judiciary of civil law nations.

    1.1. The civil law nations must to use government official gazette to publish all its legal documents... So "legal documents" here are very close to the SchemaOrgs's core Article, because each content of a journal is an article.

    1.2. Oficial archives, as LexML-BR (with 1,238,121 legislative itens and 5,471,221 precedent itens), have good collections to check semantic distions on legislative/jurisdictional documents.

  2. Document (unique) persistent identification is a basic/fundamental issue. We need a property like DOI, but there are no "universal standard" as DOI for legislation, the best that exist is a national (local) standard and persistent "ID resolver" to redirect ID to document (as dx.doi.org do)...
    The best concept is URN (DOI meets the concept of URN), and there are a "legal URN", is the URN LEX. So, for SchemaOrg users, what we need is a "URN-Resolver URL" property.

  3. Document structure, as commented here, is another important issue.

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Sep 13, 2016

@tfrancart This property just landed in Wikidata, might be useful

repeals - this document or act repeals that other document or act
https://www.wikidata.org/wiki/Property:P3148

@tfrancart This property just landed in Wikidata, might be useful

repeals - this document or act repeals that other document or act
https://www.wikidata.org/wiki/Property:P3148

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Sep 14, 2016

Contributor

@thadguidry : thanks for the pointer. Our idea was to have a generic "changes" / "changedBy" property that could then be refined into specific types of changes, like repeals, corrects, amends, commences, and so on. We will indeed propose a "repeals" property (or rather, "legislationRepeals") but for the moment I don't want to broaden the scope too much, until other comments are adressed (we are adressing them now, and should publish a v2 of the extension soon that reuses more properties from the core).

@ppKrauss :

1.1. The civil law nations must to use government official gazette to publish all its legal documents... So "legal documents" here are very close to the SchemaOrgs's core Article, because each content of a journal is an article.

We chose to leave the OfficialGazette itself out of the scope of the proposed extension, but this could be a natural subclass of Periodical. But I don't think a Legislation should be considered a subclass of Article, this would be confusing. Also we should consider that the official gazettes themselves tend to disappear, each piece of legislation being electronically published on its own.
On the same topic, there is no property in SDO, other than the generic hasPart/isPartOf, to say "that article/creative work/legislation was published in this issue of a periodical/magazine/official gazette". For the moment we chose to propose a specific property "legislationPublishedIn", subproperty of "isPartOf", because we don't want to mix with the notion of inclusion of articles/sections into piece of legislation.

Document (unique) persistent identification is a basic/fundamental issue. We need a property like DOI, but there are no "universal standard" as DOI for legislation, the best that exist is a national (local) standard and persistent "ID resolver" to redirect ID to document (as dx.doi.org do)...
The best concept is URN (DOI meets the concept of URN), and there are a "legal URN", is the URN LEX. So, for SchemaOrg users, what we need is a "URN-Resolver URL" property.

I agree with you on the importance of precise identifiers for legislation. I suggest you also take a look at ELI regarding this matter of legislation identification (basically relying on URIs). We proposed the property "legislationIdentifier" here, which I think is sufficient since schema.org does not really care about the format/standard of the identifier itself.

Document structure, as commented here, is another important issue.

We explicitely left the document structure out of scope, and concentrated only on the descriptive metadata. Note that the proposed type Legislation is defined as "A legal act or a component of a legal act (like an article)", so you can describe articles and relate them to their encompassing act with an isPartOf link.

Contributor

tfrancart commented Sep 14, 2016

@thadguidry : thanks for the pointer. Our idea was to have a generic "changes" / "changedBy" property that could then be refined into specific types of changes, like repeals, corrects, amends, commences, and so on. We will indeed propose a "repeals" property (or rather, "legislationRepeals") but for the moment I don't want to broaden the scope too much, until other comments are adressed (we are adressing them now, and should publish a v2 of the extension soon that reuses more properties from the core).

@ppKrauss :

1.1. The civil law nations must to use government official gazette to publish all its legal documents... So "legal documents" here are very close to the SchemaOrgs's core Article, because each content of a journal is an article.

We chose to leave the OfficialGazette itself out of the scope of the proposed extension, but this could be a natural subclass of Periodical. But I don't think a Legislation should be considered a subclass of Article, this would be confusing. Also we should consider that the official gazettes themselves tend to disappear, each piece of legislation being electronically published on its own.
On the same topic, there is no property in SDO, other than the generic hasPart/isPartOf, to say "that article/creative work/legislation was published in this issue of a periodical/magazine/official gazette". For the moment we chose to propose a specific property "legislationPublishedIn", subproperty of "isPartOf", because we don't want to mix with the notion of inclusion of articles/sections into piece of legislation.

Document (unique) persistent identification is a basic/fundamental issue. We need a property like DOI, but there are no "universal standard" as DOI for legislation, the best that exist is a national (local) standard and persistent "ID resolver" to redirect ID to document (as dx.doi.org do)...
The best concept is URN (DOI meets the concept of URN), and there are a "legal URN", is the URN LEX. So, for SchemaOrg users, what we need is a "URN-Resolver URL" property.

I agree with you on the importance of precise identifiers for legislation. I suggest you also take a look at ELI regarding this matter of legislation identification (basically relying on URIs). We proposed the property "legislationIdentifier" here, which I think is sufficient since schema.org does not really care about the format/standard of the identifier itself.

Document structure, as commented here, is another important issue.

We explicitely left the document structure out of scope, and concentrated only on the descriptive metadata. Note that the proposed type Legislation is defined as "A legal act or a component of a legal act (like an article)", so you can describe articles and relate them to their encompassing act with an isPartOf link.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 4, 2017

Contributor

I would like to get this into our draft next release, via pending.schema.org (which the pull request now uses, thanks @tfrancart).

We could use some review/qa/checking before doing the merge. Could someone else take a look at #1380 ... from a look at https://github.com/schemaorg/schemaorg/pull/1380/files there are some changes that I'm not sure about, e.g. to the top level README, which we probably don't want to merge.

There are (as @twamarc pointed out a while back - see #1156 (comment) ) a few properties which are pretty general. Not necessarily a bad idea, but which are not legislation-specific and deserve wider scrutiny. There are related discussions around publications and citations, for example - see #736 /cc @mfenner

The purpose of getting this into pending is to have those discussions, so we don't need to block on that, but a 2nd review of the basic file changes would be healthy.... /cc @RichardWallis

Contributor

danbri commented May 4, 2017

I would like to get this into our draft next release, via pending.schema.org (which the pull request now uses, thanks @tfrancart).

We could use some review/qa/checking before doing the merge. Could someone else take a look at #1380 ... from a look at https://github.com/schemaorg/schemaorg/pull/1380/files there are some changes that I'm not sure about, e.g. to the top level README, which we probably don't want to merge.

There are (as @twamarc pointed out a while back - see #1156 (comment) ) a few properties which are pretty general. Not necessarily a bad idea, but which are not legislation-specific and deserve wider scrutiny. There are related discussions around publications and citations, for example - see #736 /cc @mfenner

The purpose of getting this into pending is to have those discussions, so we don't need to block on that, but a 2nd review of the basic file changes would be healthy.... /cc @RichardWallis

@mfenner

This comment has been minimized.

Show comment
Hide comment
@mfenner

mfenner May 5, 2017

For scientific data our community makes use of citation, isBasedOn, or rather the reverse relationship. We are currently using @reverse, as per discussion in #1031, but would be happy to see new properties citedBy and basisFor, mainly because we almost always need the reverse (data is cited or used as basis for a scholarly article), and because the consumers of our schema.org are usually not so well-versed in linked data.

As for the wording, in general prefer references over citesor citation, as it is more generic and citation is an overloaded term in the scholarly context. Most scholars would be fine saying that a Wikipedia page references a scholarly article, but might have trouble calling it a citation.

Having said that, I am fine going what is already there, namely citation and isBasedOn, and only add the reverse properties.

#736 looks at adding a reverse property for author, i.e. Person authored CreativeWork. This is useful for a person-centric view of for example listing all scholarly publications of a person. This should be generic enough that it also works for Organization and may be relevant here. Again, this is about the general discussion whether or not to use @everse or define a new property for that relation.

mfenner commented May 5, 2017

For scientific data our community makes use of citation, isBasedOn, or rather the reverse relationship. We are currently using @reverse, as per discussion in #1031, but would be happy to see new properties citedBy and basisFor, mainly because we almost always need the reverse (data is cited or used as basis for a scholarly article), and because the consumers of our schema.org are usually not so well-versed in linked data.

As for the wording, in general prefer references over citesor citation, as it is more generic and citation is an overloaded term in the scholarly context. Most scholars would be fine saying that a Wikipedia page references a scholarly article, but might have trouble calling it a citation.

Having said that, I am fine going what is already there, namely citation and isBasedOn, and only add the reverse properties.

#736 looks at adding a reverse property for author, i.e. Person authored CreativeWork. This is useful for a person-centric view of for example listing all scholarly publications of a person. This should be generic enough that it also works for Organization and may be relevant here. Again, this is about the general discussion whether or not to use @everse or define a new property for that relation.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 11, 2017

Contributor

@tfrancart - what was the conclusion re 'relatedTo' ? it is listed above but I don't see it in the PR (which is fine by me). See also #1187 #1152.

Contributor

danbri commented May 11, 2017

@tfrancart - what was the conclusion re 'relatedTo' ? it is listed above but I don't see it in the PR (which is fine by me). See also #1187 #1152.

danbri added a commit that referenced this issue May 11, 2017

Merge pull request #1619 from tfrancart/legislation-pending-2
Moved proposed legislation extension (#1156) to pending
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 11, 2017

Contributor

I've merged in the latest PR into 'master', and published to the work-in-progress editing site, webschemas: http://pending.webschemas.org/Legislation

Please take a look and help catch any bugs or concerns before this goes out with next schema.org release.

Contributor

danbri commented May 11, 2017

I've merged in the latest PR into 'master', and published to the work-in-progress editing site, webschemas: http://pending.webschemas.org/Legislation

Please take a look and help catch any bugs or concerns before this goes out with next schema.org release.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 11, 2017

Contributor

Looking at http://pending.webschemas.org/LegalValueLevel which enumerates Authoritative,
Definitive, Official, Unofficial ... perhaps we could append LegalValue to these. In particular "Official" on its own seems open to many interpretations, including a natural reading "an official" e.g. a person/representative.

Contributor

danbri commented May 11, 2017

Looking at http://pending.webschemas.org/LegalValueLevel which enumerates Authoritative,
Definitive, Official, Unofficial ... perhaps we could append LegalValue to these. In particular "Official" on its own seems open to many interpretations, including a natural reading "an official" e.g. a person/representative.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 11, 2017

Contributor

On the question of whether we need so many inverse properties, this is rather timely. I've been working with @chaals on a cleanup/revision of W3C's version of the Microdata spec, and the issue of inverses is under consideration: w3c/microdata#2

... if we had "itemprop-inverse" or similar in the Microdata syntax, would this remove much of the pressure to name each relationship in both directions?

Contributor

danbri commented May 11, 2017

On the question of whether we need so many inverse properties, this is rather timely. I've been working with @chaals on a cleanup/revision of W3C's version of the Microdata spec, and the issue of inverses is under consideration: w3c/microdata#2

... if we had "itemprop-inverse" or similar in the Microdata syntax, would this remove much of the pressure to name each relationship in both directions?

@mfenner

This comment has been minimized.

Show comment
Hide comment
@mfenner

mfenner May 11, 2017

@danbri not from my perspective, as I am only using schema.org as JSON-LD. So the need for inverse properties has not arisen from using Microdata, but rather that it makes it easier to reuse our schema.org/JSON-LD for people not too familiar with linked data. Obviously not every property needs an inverse property, but for some of them it would help.

mfenner commented May 11, 2017

@danbri not from my perspective, as I am only using schema.org as JSON-LD. So the need for inverse properties has not arisen from using Microdata, but rather that it makes it easier to reuse our schema.org/JSON-LD for people not too familiar with linked data. Obviously not every property needs an inverse property, but for some of them it would help.

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart May 12, 2017

Contributor

@danbri : I don't see any problem to append "LegalValue" on the corresponding entries. This would result in "OfficialLegalValue", "UnofficialLegalValue", "AuthoritativeLegalValue" and "DefinitiveLegalValue".

Can I still modify the PR to do this ? create another PR ?

On inverse properties, sometimes an inverse is needed because we need to keep track of which side the relation is actually expressed.
IOW, the direction of the link can carry an information on how it was originally expressed. Saying "A citedBy B" is not totally equivalent to saying "B citation A". Saying "B citation A" because I am reviewing/annotating A might interfere with the links that someone else have created when reviewing/annotating B.

Contributor

tfrancart commented May 12, 2017

@danbri : I don't see any problem to append "LegalValue" on the corresponding entries. This would result in "OfficialLegalValue", "UnofficialLegalValue", "AuthoritativeLegalValue" and "DefinitiveLegalValue".

Can I still modify the PR to do this ? create another PR ?

On inverse properties, sometimes an inverse is needed because we need to keep track of which side the relation is actually expressed.
IOW, the direction of the link can carry an information on how it was originally expressed. Saying "A citedBy B" is not totally equivalent to saying "B citation A". Saying "B citation A" because I am reviewing/annotating A might interfere with the links that someone else have created when reviewing/annotating B.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 19, 2017

Contributor

@tfrancart - I'll make the *LegalValue change directly now.

Regarding inverses, while I think I understand your intuition, nothing in the underlying syntax (e.g. Microdata, RDFa or JSON-LD), or in Schema.org itself, supports that notion of a semi-inverse.

In schema.org, a pair of properties are inverseOf each other if reversing the direction and using the inverse property says the same thing. The two expressions are as intimately related as saying 10000 + 1 versus saying 1 + 10000.

For this stage let's include all the inverses but we ought to go deeper into this to make sure that the intended meaning here matches up with the schema.org expression. The direction of the link might give a clue about the structure of the original document, but once the data has been parsed out, lots of information is inevitably lost. BTW we are discussing adding inverse syntax into W3C's updated Microdata spec - see w3c/microdata#2 - to match the expressivity already in JSON-LD and RDFa 1.1.

Contributor

danbri commented May 19, 2017

@tfrancart - I'll make the *LegalValue change directly now.

Regarding inverses, while I think I understand your intuition, nothing in the underlying syntax (e.g. Microdata, RDFa or JSON-LD), or in Schema.org itself, supports that notion of a semi-inverse.

In schema.org, a pair of properties are inverseOf each other if reversing the direction and using the inverse property says the same thing. The two expressions are as intimately related as saying 10000 + 1 versus saying 1 + 10000.

For this stage let's include all the inverses but we ought to go deeper into this to make sure that the intended meaning here matches up with the schema.org expression. The direction of the link might give a clue about the structure of the original document, but once the data has been parsed out, lots of information is inevitably lost. BTW we are discussing adding inverse syntax into W3C's updated Microdata spec - see w3c/microdata#2 - to match the expressivity already in JSON-LD and RDFa 1.1.

danbri added a commit that referenced this issue May 19, 2017

Updated 3 enumeration values to have 'LegalValue' in their name.
Otherwise e.g. 'Official' could sound like a person / job role.
/cc #1156
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 19, 2017

Contributor

(Ahem, I had a typo. "10000 + 1 versus saying 1 + 10000.", not 1000 :)

Contributor

danbri commented May 19, 2017

(Ahem, I had a typo. "10000 + 1 versus saying 1 + 10000.", not 1000 :)

danbri added a commit that referenced this issue May 19, 2017

@johndann

This comment has been minimized.

Show comment
Hide comment
@johndann

johndann May 19, 2017

@mwkuster

This comment has been minimized.

Show comment
Hide comment
@mwkuster

mwkuster May 19, 2017

+1, being able to express inverse relationships in both directions is equally of importance for European Union legislation.

+1, being able to express inverse relationships in both directions is equally of importance for European Union legislation.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 20, 2017

Contributor

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.

Contributor

danbri commented May 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 20, 2017

Contributor

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

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

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart May 22, 2017

Contributor

(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.

Contributor

tfrancart commented May 22, 2017

(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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 22, 2017

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@f1234k

f1234k 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?

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 10, 2017

ghost commented Jul 10, 2017

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jul 11, 2017

Contributor

"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".

Contributor

tfrancart commented Jul 11, 2017

"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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 11, 2017

ghost commented Jul 11, 2017

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Jul 11, 2017

@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 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

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jul 12, 2017

Contributor

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.

Contributor

tfrancart commented Jul 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 12, 2017

ghost commented Jul 12, 2017

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 12, 2017

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@ppKrauss

ppKrauss Sep 12, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 12, 2017

Contributor

Thanks - will fix to 2017

Contributor

danbri commented Sep 12, 2017

Thanks - will fix to 2017

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Sep 20, 2017

Contributor

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

Contributor

tfrancart commented Sep 20, 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment