Each term definition should end with a period / full stop, i.e. ".".

[danbri]

We have been consistently inconsistent with this, historically. The ideal that was agreed a while back was that labels are simple strings with no ".", matching the portion of the term URI after 'schema.org/', while the description (i.e. rdfs:comment) would most properly end with a period / full stop.

This can be checked, roughly, with a SPARQL query. See: http://dydra.com/danbri/schema-org/query#comments-not-ending

SELECT * WHERE { ?p rdfs:comment ?c FILTER regex(str(?c), "[^.]\\s*$") } 

There are some corner cases and details:

• descriptions ending in markup
• descriptions ending with a raw list of URLs (i.e. those from Good Relations where we enumerate external values)

Apart from those, e4a6b88 addresses about 100 easier cases.

[danbri]

After today's changes, the following terms match the SPARQL FILTER regex(str(?c), "[^.]\s*$":

• http://schema.org/price (definition ends with use of escaped markup for a list, so a false positive)

GoodRelations-based terms that end with a list of URLs:

• http://schema.org/BusinessEntityType
• http://schema.org/BusinessFunction
• http://schema.org/DayOfWeek
• http://schema.org/DeliveryMethod
• http://schema.org/ParcelService
• http://schema.org/PaymentMethod
• http://schema.org/CreditCard
• http://schema.org/WarrantyScope

A next step could be to create a unit test to discourage the addition of term definitions that end without a final '.' - tracked as #250.

It would also be useful to improve the SPARQL filter to accept newlines and escaped '>' chars.

[danbri]

Closing this as addressed in all reasonable cases. Leaving #250 open to get a unit test in place to police the situation better in future.