-
Notifications
You must be signed in to change notification settings - Fork 15
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
Proposal: move additionalProperty up to Thing attribute #117
Comments
Describe what you need on Dataset Open separate issues for those 2 needs, so that the whole community can help you further. |
I volontary proposed this change on
(I also have some specifics on |
This was also the original design when I initially submitted the additionalProperty and PropertyValue model. Back then there was some fear that having this at the level of Thing might foster abuse in lieu of properly defined language elements. I still support widening the use of additionalProperty.
Best, Martin
…---------------------------------------
martin hepp
www: http://www.heppnetz.de/
email: mhepp@computer.org
Am 30.08.2018 um 20:46 schrieb Axel Haustant ***@***.***>:
I volontary proposed this change on Thing and not Dataset or DataDownload, because this is not the first time I tried to use it on something else.
In fact, I need it on Organization and Person too. I already needed it on other classes too.
Thing is the only common abstract ancestor which is already holding all generic properties. This is why it seems logical (to me) that additionalProperty is a Thing property.
(I also have some specifics on Dataset and DataDownload and will submit 2 other separates issues).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
What I was pretty amazed at when first learning about schema.org / JSON-LD is how restrictive the schema is towards custom / unknown properties. Why do we even need There is Why not just ignore unknown fields?? I understand it could give collisions later on when fields with the same name are added to the spec, but that could be easily solved with a naming convention (e.g. custom property names should start with an underscore). Imho, the way it currently works, makes schema.org much less flexible a tool for many purposes. For example I investigated using schema.org entity types as the model for a web api, but the problem I run into is that adding custom properties is either ugly / impossible (as this issue demonstrates) via |
To be clear, additional property is a pretty weak approach in the sense that it handles very well the case where we don't really know what the properties are. This is common in ecommerce, where a site might have foo=bar, xyz=1000, or for geo/place, things like horse=true. Aside from these you can always mix in other vocabularies, regardless of whether they are presented as "extensions" (like gs1.org/voc) to Schema.org or not. Whether search engine features make much use of these is beyond schema.org's remit, but the data structure is perfectly sensible and useful. So as @mfhepp says, we shouldn't encourage over-use of additionalProperty when normal properties from nearby vocabularies can be used instead. |
I think using I don't see
I think would be easier to detect a recurrent Plus, I've been looking into issues, and a recurrent response is: "You should use
|
Ping @rvguha - what do you think? |
I second this proposal. Furthermore, https://schema.org/additionalProperty claims it applies to
|
Are there remaining issues to discuss here? |
No, I think we can simply go forward. As I was the original designer of this proposal, I would like to explain the motivation a bit: There are many cases where publishers of data have identifiers for clearly defined properties. This can be either properties applied to all products in a shop, or properties from external standards like eCl@ss. For those properties, we at least have a site-specific unique name or even a globally unique identifier from the external standard. additionalProperty allows publishers to expose as much data semantics as they reasonably can without imposing a lot of additional barriers. This is better than a black or white approach where the property is either in schema.org or not supported. The full rationale is described here: https://www.w3.org/wiki/WebSchemas/PropertyValuePairs |
I would prefer to hold off on such a radical move.
…On Fri, Nov 15, 2019 at 2:49 AM Martin Hepp ***@***.***> wrote:
No, I think we can simply go forward.
As I was the original designer of this proposal, I would like to explain
the motivation a bit:
There are many cases where publishers of data have identifiers for clearly
defined properties. This can be either properties applied to all products
in a shop, or properties from external standards like ***@***.***
For those properties, we at least have a site-specific unique name or even
a globally unique identifier from the external standard.
additionalProperty allows publishers to expose as much data semantics as
they reasonably can without imposing a lot of additional barriers. This is
better than a black or white approach where the property is either in
schema.org or not supported.
The full rationale is described here:
https://www.w3.org/wiki/WebSchemas/PropertyValuePairs
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/schemaorg/schemaorg/issues/2047?email_source=notifications&email_token=ABICKCRMDRDS3LTWXGEW24TQTZ5FNA5CNFSM4FSP6EQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEFCE6Q#issuecomment-554312314>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABICKCTDFCBICFVBEMEB2N3QTZ5FNANCNFSM4FSP6EQQ>
.
|
Agree with @rvguha here. Schema.org is not a closed system, you can always add additional properties from other vocabularies when they're missing in schema.org. It would be better to encourage that practice than to add an extra layer of indirection. The case of Product is reasonably special, aggregators do have useful property/value pairs that they barely understand. But we added a health warning into PropertyValue for good reason...
|
To advocate for this, there is some benefit to allowing developers to use https://schema.org/additionalProperty for experimenting before they get the schema correct. As examples, there was some discussion in issue schemaorg/schemaorg#561 about the language at the other end of https://schema.org/EntryPoint. I would not say we have an answer yet, but using additionalProperty in WatchAction links has allowed some experimentation in the sorts of parameters a data reader might want. I still hope we can codify a good pattern for structuring this data. Similarly, Google once used additionalProperty to understand JobPostings but once the space was clearer, worked with the community to adopt https://schema.org/jobLocationType. I would not expect any reader to understand all uses of additionalProperty, but there are times like @mfhepp suggests where some data is better than none, particularly when exploring areas where authors have not previously provided structured data. |
I am not a fan of PropertyValue. It is basically an escape mechanism out of
using schema.org vocabulary, while claiming to be using schema.org.
And in doing so, it changes the structure of the graph.
If schema.org does not have the vocabulary things are much cleaner if you
created new vocabulary in whatever namespace and used it.
guha
…On Fri, Nov 15, 2019 at 12:23 PM Vicki Tardif ***@***.***> wrote:
To advocate for this, there is some benefit to allowing developers to use
https://schema.org/additionalProperty for experimenting before they get
the schema correct.
As examples, there was some discussion in issue schemaorg/schemaorg#561
<schemaorg/schemaorg#561> about the language at
the other end of https://schema.org/EntryPoint. I would not say we have
an answer yet, but using additionalProperty in WatchAction links
<https://developers.google.com/actions/media/reference/feed-examples/watch-actions-examples#additionalproperty>
has allowed some experimentation in the sorts of parameters a data reader
might want. I still hope we can codify a good pattern for structuring this
data.
Similarly, Google once used additionalProperty to understand JobPostings
<https://developers.google.com/search/docs/data-types/job-posting> but
once the space was clearer, worked with the community to adopt
https://schema.org/jobLocationType.
I would not expect any reader to understand all uses of
additionalProperty, but there are times like @mfhepp
<https://github.com/mfhepp> suggests where some data is better than none,
particularly when exploring areas where authors have not previously
provided structured data.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/schemaorg/schemaorg/issues/2047?email_source=notifications&email_token=ABICKCT2445B43MKDTJXODDQT4AMBA5CNFSM4FSP6EQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEGTOAA#issuecomment-554514176>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABICKCVMIURK4KSUZPWLCOTQT4AMBANCNFSM4FSP6EQQ>
.
|
While I share that concern, there are circumstances (like long-tail
ecommerce properties) where it has value. Generally wherever the party
creating the markup (e.g. wordpress extension author, seo) is not the party
responsible for - and knowledgeable about - the underlying set of
properties, or where they wouldn't really know how to "create new
vocabulary in whatever namespace" anyway.
Maybe a "free for all" chaotic namespace like http://anything.example.org/
would allow this, for publishers who don't want to set up one for their own
specific property set, e.g. in JSON-LD:
{ "@context": ["https://schema.org/", "http://anything.example.org/"],
"@type": "Person", "name": "Alice", "foo": "bar" }
.. but doing this (following the json-ld context rules) would make it
difficult to know whether "foo" was a typo of a term in schema.org that
should be challenged in validation, or a term from the "anything goes"
namespace.
…On Sun, 17 Nov 2019 at 02:20, R.V.Guha ***@***.***> wrote:
I am not a fan of PropertyValue. It is basically an escape mechanism out of
using schema.org vocabulary, while claiming to be using schema.org.
And in doing so, it changes the structure of the graph.
If schema.org does not have the vocabulary things are much cleaner if you
created new vocabulary in whatever namespace and used it.
guha
On Fri, Nov 15, 2019 at 12:23 PM Vicki Tardif ***@***.***>
wrote:
> To advocate for this, there is some benefit to allowing developers to use
> https://schema.org/additionalProperty for experimenting before they get
> the schema correct.
>
> As examples, there was some discussion in issue schemaorg/schemaorg#561
> <schemaorg/schemaorg#561> about the language
at
> the other end of https://schema.org/EntryPoint. I would not say we have
> an answer yet, but using additionalProperty in WatchAction links
> <
https://developers.google.com/actions/media/reference/feed-examples/watch-actions-examples#additionalproperty
>
> has allowed some experimentation in the sorts of parameters a data reader
> might want. I still hope we can codify a good pattern for structuring
this
> data.
>
> Similarly, Google once used additionalProperty to understand JobPostings
> <https://developers.google.com/search/docs/data-types/job-posting> but
> once the space was clearer, worked with the community to adopt
> https://schema.org/jobLocationType.
>
> I would not expect any reader to understand all uses of
> additionalProperty, but there are times like @mfhepp
> <https://github.com/mfhepp> suggests where some data is better than
none,
> particularly when exploring areas where authors have not previously
> provided structured data.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
https://github.com/schemaorg/schemaorg/issues/2047?email_source=notifications&email_token=ABICKCT2445B43MKDTJXODDQT4AMBA5CNFSM4FSP6EQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEGTOAA#issuecomment-554514176
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ABICKCVMIURK4KSUZPWLCOTQT4AMBANCNFSM4FSP6EQQ
>
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<https://github.com/schemaorg/schemaorg/issues/2047?email_source=notifications&email_token=AABJSGNLHI6EXECNZWVKJFDQUCS6HA5CNFSM4FSP6EQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEH7U6I#issuecomment-554695289>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJSGIYPEZMD2CW3NCTDUTQUCS6HANCNFSM4FSP6EQQ>
.
|
See issue #7 for the context of the move from the main Schema.org issue tracker to this repository. |
Right now, the only mecanism allowing to extra custom properties is
additionalProperty
.There is a lot of issues advising to use this attribute to declare extra custom properties but, sadly, it's only available on a very small subset of classes:
Place
Product
QualitativeValue
QuantitiveValue
So the proposal is to make
additionalProperty
aThing
property because this property is non-specific, not domain related.This will allow every child class to benefit from it (in my case I need it in particular on
Dataset
andDataDownload
).The text was updated successfully, but these errors were encountered: