Skip to content
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
Closed

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

vholland opened this issue May 20, 2015 · 16 comments
Assignees

Comments

@vholland
Copy link
Contributor

@vholland 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
Copy link
Contributor Author

@vholland vholland commented May 21, 2015

Implemented as pull request #523.

@danbri
Copy link
Contributor

@danbri danbri commented May 22, 2015

/cc @mfhepp

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

@chaals chaals commented May 28, 2015

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

@mfhepp
Copy link
Contributor

@mfhepp 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
Copy link
Contributor

@danbri 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
Copy link
Contributor

@danbri danbri commented Jun 10, 2015

Done (manually)

@danbri
Copy link
Contributor

@danbri 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
Copy link
Contributor

@danbri danbri commented Jun 10, 2015

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

@vholland
Copy link
Contributor Author

@vholland vholland commented Jun 10, 2015

+1 OrderPaymentDue

@danbri
Copy link
Contributor

@danbri 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
Copy link
Contributor

@danbri danbri commented Jun 11, 2015

action: danbri test if multiple typing works

@scor
Copy link
Contributor

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

@danbri 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
Copy link
Contributor

@danbri 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
Copy link
Contributor Author

@vholland 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
This clarifies its meaning and makes room for PaymentDue as an enumerated
status value. For #518
@danbri
Copy link
Contributor

@danbri 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
…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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.