Add security and access control/attributes á la Web Api

[beyond-code-github]

With the standard Web API OData offering you can do this:

http://blogs.msdn.com/b/webdev/archive/2013/02/06/protect-your-queryable-api-with-validation-feature-in-asp-net-web-api-odata.aspx

Linq to Querystring needs a similar feature. (also requested by @corneliuskopp)

[philbarker]

I guess, so long as schema.org's aims are limited to global/world-wide, but no more

[thadguidry]

@philbarker Now Phil...you know you'd be the first to book that Martian Hut for a week with that killer view of rock and sand. :)

[mfhepp]

I object this, because the current range of http://schema.org/QuantitativeValue allows using

• multiple units of measurements (kg, ounces, etc. based on UNCEFACT Common Codes)
• point values, closed and open intervals (1 kg, up to 1 kg, 1 kg or less)
• value references (1kg at a certain humidity or date)

etc.

The whole http://schema.org/QuantitativeValue model is a very powerful mechanism for quantitative values of any kind. Mass is from the older branch of schema.org and much weaker.

Now, you could argue to make http://schema.org/Mass a subtype of http://schema.org/QuantitativeValue. Conceptually, this makes sense, but practically, you will make generating markup much more powerful, because when e.g. converting a table of product features into markup, you have to guess which properties refer to a mass and then change the markup pattern for these properties from http://schema.org/QuantitativeValue to http://schema.org/Mass.

Such case-by-case variations of markup patterns are from hell for Web developers, and they gain very little for the consumer of the data. The latter can guess from a set of UN/CEFACT Common Codes that the quantitative value or the property refers to a mass anyway. And without standardizing the semantics of the property (which is difficult across a broad array of contexts - product weights, weights in scientific experiments, etc.), little is gained.

Keep in mind that schema:weight is actually pretty ambigous - does it mean "item weight", "item weight with accessories/cabling", or "package weight"?

Globally shared vocabularies are complex systems with many side-effects. Striving for more conceptual clarity does not automatically improve the ability of consumers of the data to interpret it properly, e.g. because of adverse effects on data quality (e.g. people will make more mistakes or fill in nonsense) or data coverage (people will not populate properties that are too difficult to derive from existing databases).

Best wishes

Martin

---

martin hepp http://www.heppnetz.de [email protected] @mfhepp

On 05 May 2017, at 15:44, Thad Guidry [email protected] wrote:

@philbarker Now Phil...you know you'd be the first to book that Martian Hut for a week with that killer view of rock and sand. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[espinr]

I agree http://schema.org/QuantitativeValue (+UN/CEFACT codes) is the best approach in this case. Automatic processing of http://schema.org/Mass ("1 kg") and http://schema.org/Distance ("1 m") is more difficult than http://schema.org/QuantitativeValue (less natural text, less ambiguity).

My comment was just to align the existing classes/properties —a similar same case as seen in height—.

So, perhaps Mass, Distance and Energy should be deprecated.

[dr-shorthair]

Of course a physicist (or even high school applied math student) would object to equating 'weight' and 'mass'. Weight is a force; Mass is a measure of 'resistance to acceleration under the influence of a force', and is related to amount-of-substance.

[espinr]

Yes, but most of people undestand the most common definition of 'weight'.- A body's relative mass or the quantity of matter contained by it, giving rise to a downward force; the heaviness of a person or thing. ‘he was at least 175 pounds in weight’.

I know, physicists would say: 'he was at least 784 N in weight (at sea level)' :-)

This ambiguity, as well as the mentioned case of ponderation weight, could be solved with a better description of the property. It comes from GoodRelations and it's represented as mass in all cases I've seen.

[danbri]

Re mass vs force - yes, I believe this was @philbarker 's point above.

Ok, so to make a horrible metaphor, there are different forces operating upon us here.

• Our vocabulary around quantities currently suffers from having two different co-existing designs; the original one which favours expression of units within informally structured strings, and the later Good Relations approach which we merged in but didn't fully integrate with the earlier approach.
• In the spirit of https://xkcd.com/927/ and partially motivated by iot.schema.org we are in schemaorg/schemaorg#1390 looking at reconciling these two competing approaches in the light of a broader effort based on integrating QUDT. This leans towards standard scientific metrics but we'll need to adapt that to the distinctive deployment environment enjoyed by schema.org.
• Schema.org has a long heritage of allowing a single property to serve a cluster of related purposes, distinguished by the types of the entities that the property relates. For example, http://schema.org/width has usecases around MediaObject (where a width might be in pixels) as well as in describing physical Products whose width might be in millimeters.

My suggestion would be to adapt the definition of 'weight'. We might add a sentence along the lines of

While in a scientific context a weight is formally a force, and this usage is supported, a common use of schema.org 'weight' is for representing mass

... though we'd still need to clarify the Mass vs QuantitativeValue tradeoffs @mfhepp discusses above. I hope something will come out of discussions around QUDT that gives us a project-wide pattern, it would be unfortunate to solve these issues solely for 'weight'.

[dr-shorthair]

My pedantic comment about weight vs mass was a little tongue-in-cheek (with long memories of some high school teacher's rules).

However, this does highlight another concern I have about the name of the variableMeasured property - 'measure' usually generates a quantitative value. What about qualitative (categorical) values?

[Aaranged]

Regardless of the outcome of this particular issue, may I suggest on a tangential note that we add examples to the QuantitativeValue page?

Something as simple as saying "the blue widget weighs 1 kg" using QuantitativeValue is hell for web developers who have never heard of a "UN/CEFACT Common Code" and are accustomed to being able to provide such values in a "width"-type fashion (i.e. "weight": "1 kg"), despite the ambiguity this entails.

[github-actions[bot]]

This issue is being tagged as Stale due to inactivity.

[danbri]

Let's keep this issue open, but I think we're in brainstorming territory for now

[RichardWallis]

See issue #7 for the context of the move from the main Schema.org issue tracker to this repository.