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

Add enumerated values for http://schema.org/paymentStatus #518

Closed
vholland opened this Issue May 20, 2015 · 16 comments

Comments

Projects
None yet
5 participants
@vholland
Contributor

vholland commented May 20, 2015

http://schema.org/paymentStatus takes text. It would be nice to also take defined values. Initially, we should support the following and maybe others.

PaymentComplete
PaymentDue
PaymentPastDue
PaymentDeclined

@vholland vholland self-assigned this May 20, 2015

vholland added a commit to vholland/schemaorg that referenced this issue May 21, 2015

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland May 21, 2015

Contributor

Implemented as pull request #523.

Contributor

vholland commented May 21, 2015

Implemented as pull request #523.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 22, 2015

Contributor

/cc @mfhepp

Contributor

danbri commented May 22, 2015

/cc @mfhepp

@danbri danbri added this to the sdo-ganymede release milestone May 22, 2015

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals May 28, 2015

Contributor

WfM. The feature creep in me looks for a partial payment made…

Contributor

chaals commented May 28, 2015

WfM. The feature creep in me looks for a partial payment made…

@mfhepp

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp May 28, 2015

Contributor

@chaals is right - we likely need a mechanism for deposits and partial payment. Would PartialPaymentReceived as an additional value be sufficient?

Contributor

mfhepp commented May 28, 2015

@chaals is right - we likely need a mechanism for deposits and partial payment. Would PartialPaymentReceived as an additional value be sufficient?

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 10, 2015

Contributor

Per rough consensus in #587 I'm going to merge in #523. If there's interest her in addressing the partial payment / deposit angle, please continue here and we can refine.

Contributor

danbri commented Jun 10, 2015

Per rough consensus in #587 I'm going to merge in #523. If there's interest her in addressing the partial payment / deposit angle, please continue here and we can refine.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 10, 2015

Contributor

Done (manually)

Contributor

danbri commented Jun 10, 2015

Done (manually)

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 10, 2015

Contributor

Looking at this, the enumeration wasn't showing up. I've tweaked the design from the pull request, s/Intangible/Enumeration/ and that does the job.

We might also consider that PaymentDue ("The payment is due, but still within an acceptable time to be received.") is named almost identically to the existing property http://schema.org/paymentDue ("The date that payment is due."). I would prefer not to do this - can we rename it to something more distinctive?

Related (if only by similar name) existing terms:

Contributor

danbri commented Jun 10, 2015

Looking at this, the enumeration wasn't showing up. I've tweaked the design from the pull request, s/Intangible/Enumeration/ and that does the job.

We might also consider that PaymentDue ("The payment is due, but still within an acceptable time to be received.") is named almost identically to the existing property http://schema.org/paymentDue ("The date that payment is due."). I would prefer not to do this - can we rename it to something more distinctive?

Related (if only by similar name) existing terms:

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 10, 2015

Contributor

See http://webschemas.org/PaymentStatusType for current release candidate (also in sdo-ganymede)

Contributor

danbri commented Jun 10, 2015

See http://webschemas.org/PaymentStatusType for current release candidate (also in sdo-ganymede)

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jun 10, 2015

Contributor

+1 OrderPaymentDue

Contributor

vholland commented Jun 10, 2015

+1 OrderPaymentDue

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 10, 2015

Contributor

That's from a different enumeration called http://schema.org/OrderStatus whose values are already:

OrderCancelled
OrderDelivered
OrderInTransit
OrderPaymentDue
OrderPickupAvailable
OrderProblem
OrderProcessing
OrderReturned

Are these two views of the same transactions? I don't know if one enumerated value being in both enumerated lists will work very well (technically, at least).

Contributor

danbri commented Jun 10, 2015

That's from a different enumeration called http://schema.org/OrderStatus whose values are already:

OrderCancelled
OrderDelivered
OrderInTransit
OrderPaymentDue
OrderPickupAvailable
OrderProblem
OrderProcessing
OrderReturned

Are these two views of the same transactions? I don't know if one enumerated value being in both enumerated lists will work very well (technically, at least).

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 11, 2015

Contributor

action: danbri test if multiple typing works

Contributor

danbri commented Jun 11, 2015

action: danbri test if multiple typing works

@scor

This comment has been minimized.

Show comment
Hide comment
@scor

scor Jun 11, 2015

Contributor

Note that http://schema.org/OrderStatus and http://schema.org/orderStatus also both exist. I agree this should be avoided.

Since enumeration items are types in schema.org, this is prone to happen again. Is there a lot of value in having those as types as opposed to literal values which would not be clashing with the types?

Contributor

scor commented Jun 11, 2015

Note that http://schema.org/OrderStatus and http://schema.org/orderStatus also both exist. I agree this should be avoided.

Since enumeration items are types in schema.org, this is prone to happen again. Is there a lot of value in having those as types as opposed to literal values which would not be clashing with the types?

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 30, 2015

Contributor

Looking at this for the upcoming release, I am wary of (a) having one term (OrderPaymentDue) appear in two enumerations, as this will confuse navigation. The option (b) of converging the two lists I also believe unappealing, as they currently each address different situations: http://schema.org/OrderStatus vs http://sdo-ganymede.appspot.com/PaymentStatusType.

I believe the simplest fix which allows us to proceed and improves clarity of existing terms is for the current paymentDue property to migrate to an new more explicit name: paymentDueDate.

Contributor

danbri commented Jul 30, 2015

Looking at this for the upcoming release, I am wary of (a) having one term (OrderPaymentDue) appear in two enumerations, as this will confuse navigation. The option (b) of converging the two lists I also believe unappealing, as they currently each address different situations: http://schema.org/OrderStatus vs http://sdo-ganymede.appspot.com/PaymentStatusType.

I believe the simplest fix which allows us to proceed and improves clarity of existing terms is for the current paymentDue property to migrate to an new more explicit name: paymentDueDate.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 30, 2015

Contributor
rdfa schema.rdfa | grep -i date | grep Property | awk '{print $1}'
    <http://schema.org/productionDate>
    <http://schema.org/scheduledPaymentDate>
    <http://schema.org/orderDate>
    <http://schema.org/liveBlogUpdate>
    <http://schema.org/candidate>
    <http://schema.org/dateModified>
    <http://schema.org/datePublished>
    <http://schema.org/releaseDate>
    <http://schema.org/candidate>
    <http://schema.org/endDate>
    <http://schema.org/dateline>
    <http://schema.org/startDate>
    <http://schema.org/dissolutionDate>
    <http://schema.org/uploadDate>
    <http://schema.org/vehicleModelDate>
    <http://schema.org/deathDate>
    <http://schema.org/foundingDate>
    <http://schema.org/dateCreated>
    <http://schema.org/purchaseDate>
    <http://schema.org/dateIssued>
    <http://schema.org/birthDate>
    <http://schema.org/previousStartDate>
    <http://schema.org/guidelineDate>
    <http://schema.org/dateVehicleFirstRegistered>
    <http://schema.org/datePosted>

Bit of research to answer the question...

Q: Should property names end with 'date' or start with 'date'?
A: Yes.

Contributor

danbri commented Jul 30, 2015

rdfa schema.rdfa | grep -i date | grep Property | awk '{print $1}'
    <http://schema.org/productionDate>
    <http://schema.org/scheduledPaymentDate>
    <http://schema.org/orderDate>
    <http://schema.org/liveBlogUpdate>
    <http://schema.org/candidate>
    <http://schema.org/dateModified>
    <http://schema.org/datePublished>
    <http://schema.org/releaseDate>
    <http://schema.org/candidate>
    <http://schema.org/endDate>
    <http://schema.org/dateline>
    <http://schema.org/startDate>
    <http://schema.org/dissolutionDate>
    <http://schema.org/uploadDate>
    <http://schema.org/vehicleModelDate>
    <http://schema.org/deathDate>
    <http://schema.org/foundingDate>
    <http://schema.org/dateCreated>
    <http://schema.org/purchaseDate>
    <http://schema.org/dateIssued>
    <http://schema.org/birthDate>
    <http://schema.org/previousStartDate>
    <http://schema.org/guidelineDate>
    <http://schema.org/dateVehicleFirstRegistered>
    <http://schema.org/datePosted>

Bit of research to answer the question...

Q: Should property names end with 'date' or start with 'date'?
A: Yes.

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jul 30, 2015

Contributor

We also confuse 'date' and 'time'. See issue #524

Contributor

vholland commented Jul 30, 2015

We also confuse 'date' and 'time'. See issue #524

danbri added a commit that referenced this issue Jul 30, 2015

Renaming paymentDue property to paymentDueDate.
This clarifies its meaning and makes room for PaymentDue as an enumerated
status value. For #518
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 30, 2015

Contributor

Ok, I think we're done here. Please review c/o http://sdo-ganymede.appspot.com/docs/releases.html#sdo-ganymede

Contributor

danbri commented Jul 30, 2015

Ok, I think we're done here. Please review c/o http://sdo-ganymede.appspot.com/docs/releases.html#sdo-ganymede

@danbri danbri closed this Jul 30, 2015

danbri added a commit that referenced this issue Jun 21, 2016

Added: schema:paymentStatus schema:rangeIncludes schema:PaymentStatus…
…Type

See also #1203 #518
This restores accidental rollback between v2.2 and v3.0.

This change was missed during first phase of repair, but caught due to
issue-by-issue checking of releases.html.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment