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

Linked Open Data: extend rangeIncludes of 'genre' + 'keywords' properties of CreativeWork to include URL #346

Closed
lazaruscorporation opened this Issue Feb 18, 2015 · 4 comments

Comments

Projects
None yet
4 participants
@lazaruscorporation
Contributor

lazaruscorporation commented Feb 18, 2015

Hi

I'd like to suggest extending the rangeIncludes of the 'genre' and 'keywords' property of schema.org/CreativeWork (currently just "Text") to also include URL.

This will allow advanced users to implement more Linked Open Data (LOD) in schema.org, by replacing a free-typed text string in 'genre' or 'keywords' with a URI from a LOD vocabulary.

For example, the "genre" property for a Late Renaissance painting (marked up using VisualArtwork, a sub-Type of CreativeWork) could be set to the Getty AAT LOD URI "http://vocab.getty.edu/aat/300021143" instead of the text value "Late Renaissance".

Similar LOD URIs (e.g. from Wikidata etc.) could be used in the "keywords" property.

There may be other properties that can be included in this enhancement to incorporate LOD, but these two seemed the most obvious.

Thanks,

Paul

@lazaruscorporation

This comment has been minimized.

Show comment
Hide comment
@lazaruscorporation

lazaruscorporation Feb 19, 2015

Contributor

Edit: following the resolution of #347 (thanks to @danbri and @Dataliberate) this request to extend the rangeIncludes to URL (in addition to text) should only apply to the "genre" property, not the "keywords" property

Contributor

lazaruscorporation commented Feb 19, 2015

Edit: following the resolution of #347 (thanks to @danbri and @Dataliberate) this request to extend the rangeIncludes to URL (in addition to text) should only apply to the "genre" property, not the "keywords" property

@realworldobject

This comment has been minimized.

Show comment
Hide comment
@realworldobject

realworldobject Mar 16, 2015

I agree this would be very helpful for improving library linked data because we could leverage multilingual labels and descriptions such as with http://www.wikidata.org/entity/Q24925.

realworldobject commented Mar 16, 2015

I agree this would be very helpful for improving library linked data because we could leverage multilingual labels and descriptions such as with http://www.wikidata.org/entity/Q24925.

@niklasl

This comment has been minimized.

Show comment
Hide comment
@niklasl

niklasl Mar 16, 2015

+1

This has come up before, during the SKOS discussion now tracked in issue #251.

(There is a larger question about whether rangeIncludes URL implies Thing, and perhaps whether genre should be narrowed to e.g. Intangible. But since URL is already used like this elsewhere, this specific case might not be the place to resolve that.)

niklasl commented Mar 16, 2015

+1

This has come up before, during the SKOS discussion now tracked in issue #251.

(There is a larger question about whether rangeIncludes URL implies Thing, and perhaps whether genre should be narrowed to e.g. Intangible. But since URL is already used like this elsewhere, this specific case might not be the place to resolve that.)

RichardWallis pushed a commit that referenced this issue Jul 17, 2015

wallisr
Added Bridge type - issue #207
Added URL to range of genre - issue #346
Added Report type and reportNumber property - #374
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 4, 2016

Contributor

Looking at this again, I see that we implemented it for /genre (with an accidental rollback fixed in #1203 and about to be republished in v3.1, see #1212). But we didn't get there for /keywords. I see also @lazaruscorporation retracted the proposal to do this for /keywords, and that anyway we're discussing that kind of functionality elsewhere including #251. I'm therefore going to close this issue. Thanks everyone!

Contributor

danbri commented Aug 4, 2016

Looking at this again, I see that we implemented it for /genre (with an accidental rollback fixed in #1203 and about to be republished in v3.1, see #1212). But we didn't get there for /keywords. I see also @lazaruscorporation retracted the proposal to do this for /keywords, and that anyway we're discussing that kind of functionality elsewhere including #251. I'm therefore going to close this issue. Thanks everyone!

@danbri danbri closed this Aug 4, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment