-
Notifications
You must be signed in to change notification settings - Fork 822
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
Property values proposal as a separate pull request #377
Conversation
@@ -9167,10 +9174,13 @@ Note that Event uses startDate/endDate instead of startTime/endTime, even when d | |||
</div> | |||
<div typeof="rdf:Property" resource="http://schema.org/value"> | |||
<span class="h" property="rdfs:label">value</span> | |||
<span property="rdfs:comment">The value of the product characteristic.</span> | |||
<span property="rdfs:comment">The value of the quantitative value or property value node. For QuantitativeValue, the recommended type for values is 'Number'. For PropertyValue, it can be 'Text;', 'Number', 'Boolean', or 'StructuredValue'.</span> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to add StructuredValue to the range? It is mentioned in the comment, but not listed in the ranges.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks - forgot that one! Fix comes in a minute!
…additionalProperty
I fixed the description for unitText as requested in the email dated Jan 9, too. Note that unitText is really important - one one hand, we do want people to use proper UNCEFACT Common Codes when they can, because they are much more reliable and allow unit conversion etc. On the other hand, we want people to publish unit information as text when they cannot do better. Having two separate properties for this maintains backward compatibility with the original GoodRelations model, tools, and data, and reduces the task for a consuming client. |
This pull request is now ready for inclusion in sdo-gozer, following yesterday's discussions. |
And works for me... |
Git says I can't merge this automatically, but should be easy enough. Will finish merge and update gozer test site within the week... |
Maybe this is because after you merged the auto proposal, this is no longer from the same codebase. I can try to update the pull request. |
Sync with next iteration of sdo-gozer
Hi Dan: I fixed this, the pull request can now be automatically merged: The cause, afaics, was that the property-values proposal and the automotive proposal added lines in the very same region and git assumed this to be potential conflicts, while they were just sequential additions. martin hepp http://www.heppnetz.de On 25 Mar 2015, at 00:38, Dan Brickley notifications@github.com wrote:
|
Property values proposal as a separate pull request
This is the property-values proposal turned into a separate contribution, as per
#263
It can be used for product properties, EXIF data, and will be useful for the separate automotive extension.
For the full background of the proposal, see https://www.w3.org/wiki/WebSchemas/PropertyValuePairs.