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

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

Projects

None yet

5 participants

@vholland
Contributor

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
Contributor

Implemented as pull request #523.

@danbri
Contributor
danbri commented May 22, 2015

/cc @mfhepp

@danbri danbri added this to the sdo-ganymede release milestone May 22, 2015
@chaals
Contributor
chaals commented May 28, 2015

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

@mfhepp
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
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
Contributor
danbri commented Jun 10, 2015

Done (manually)

@danbri
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
Contributor
danbri commented Jun 10, 2015

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

@vholland
Contributor

+1 OrderPaymentDue

@danbri
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
Contributor
danbri commented Jun 11, 2015

action: danbri test if multiple typing works

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

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

@danbri danbri added a commit that referenced this issue Jul 30, 2015
@danbri danbri Renaming paymentDue property to paymentDueDate.
This clarifies its meaning and makes room for PaymentDue as an enumerated
status value. For #518
4989219
@danbri
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 danbri pushed a commit that referenced this issue Jun 21, 2016
Dan Brickley 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.
355d616
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment