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

serviceAudience vs. audience #145

Closed
elf-pavlik opened this Issue Oct 7, 2014 · 9 comments

Comments

Projects
None yet
4 participants
@elf-pavlik
Contributor

elf-pavlik commented Oct 7, 2014

http://schema.org/audience
http://schema.org/serviceAudience

related email: http://lists.w3.org/Archives/Public/public-vocabs/2014Oct/0023.html

I would suggest removing serviceAudience and using generic audience. If some reasons exist for not doing so maybe at least defining serviceAudience as subPropertyOf audience?

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik Oct 7, 2014

Contributor

BTW Service may need some more tweaking, currently
Service --{serviceArea}--> AdministrativeArea
Service --{serviceAudience}--> Audience --{geographicArea}--> AdministrativeArea

Contributor

elf-pavlik commented Oct 7, 2014

BTW Service may need some more tweaking, currently
Service --{serviceArea}--> AdministrativeArea
Service --{serviceAudience}--> Audience --{geographicArea}--> AdministrativeArea

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik Oct 7, 2014

Contributor

also http://schema.org/serviceType doesn't make much sense to my, maybe better to allow additionalType to accept Text since people focusing on RDF will most likely use multiple values on type ?

Contributor

elf-pavlik commented Oct 7, 2014

also http://schema.org/serviceType doesn't make much sense to my, maybe better to allow additionalType to accept Text since people focusing on RDF will most likely use multiple values on type ?

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jan 21, 2015

Contributor

@elf-pavlik 's proposal seems sensible to me. @vholland - any thoughts?

Contributor

danbri commented Jan 21, 2015

@elf-pavlik 's proposal seems sensible to me. @vholland - any thoughts?

@danbri danbri added this to the 2015 Q1 milestone Jan 21, 2015

@danbri danbri self-assigned this Jan 21, 2015

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jan 21, 2015

Contributor

Sounds good to me.

Contributor

vholland commented Jan 21, 2015

Sounds good to me.

elf-pavlik added a commit to elf-pavlik/schemaorg that referenced this issue Jan 25, 2015

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jan 25, 2015

Contributor

Thanks. Historically it is pretty rare for us to actually erase terms, so far we usually just mark as supersededBy. In this case maybe that is too conservative and best to avoid clutter. Any thoughts?

Contributor

danbri commented Jan 25, 2015

Thanks. Historically it is pretty rare for us to actually erase terms, so far we usually just mark as supersededBy. In this case maybe that is too conservative and best to avoid clutter. Any thoughts?

@sesuncedu

This comment has been minimized.

Show comment
Hide comment
@sesuncedu

sesuncedu Jan 25, 2015

Contributor

You could mark the obsolete terms in HTML with . In the type rendering
you could group the obsoleted terms together with the term that obsoleted
them.

I've been treating superseded as implying sub property and obsolete .

The sub property relationship might be wrong, if a superseding property can
have a narrower meaning than the older term.

Contributor

sesuncedu commented Jan 25, 2015

You could mark the obsolete terms in HTML with . In the type rendering
you could group the obsoleted terms together with the term that obsoleted
them.

I've been treating superseded as implying sub property and obsolete .

The sub property relationship might be wrong, if a superseding property can
have a narrower meaning than the older term.

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik Feb 7, 2015

Contributor

@danbri if you like I can revert | drop this change and then use schema:supersededBy instead!

Contributor

elf-pavlik commented Feb 7, 2015

@danbri if you like I can revert | drop this change and then use schema:supersededBy instead!

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Feb 7, 2015

Contributor

Yes, I think schema:supersededBy would be most appropriate here. @elf-pavlik could you tweak your branch that #285 draws from? I've filed this for the next release, and can't see it proving controversial.

Simon is right that we could say more about what it means. We have never said that it implies subPropertyOf, since it is easy enough to assert that independently at the same time where needed.

In this case I believe serviceAudience would also be a sub-property of audience.

Contributor

danbri commented Feb 7, 2015

Yes, I think schema:supersededBy would be most appropriate here. @elf-pavlik could you tweak your branch that #285 draws from? I've filed this for the next release, and can't see it proving controversial.

Simon is right that we could say more about what it means. We have never said that it implies subPropertyOf, since it is easy enough to assert that independently at the same time where needed.

In this case I believe serviceAudience would also be a sub-property of audience.

@danbri danbri modified the milestones: sdo-gozer release, 2015 Q1 Apr 16, 2015

danbri added a commit that referenced this issue Apr 16, 2015

Merge pull request #285 from elf-pavlik/issue-145
removed serviceAudience and reused audience rel #145

danbri added a commit that referenced this issue Apr 16, 2015

Merge pull request #430 from schemaorg/revert-285-issue-145
Revert "removed serviceAudience and reused audience rel #145"
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 16, 2015

Contributor

I've implemented this manually after failing with the pull request. I tweaked the definition to be "An intended audience, i.e. a group for whom something was created." rather than use "item" or "subject" to refer to the thing that has the audience. Also "an" rather than "the" since the property is repeatable.

Contributor

danbri commented Apr 16, 2015

I've implemented this manually after failing with the pull request. I tweaked the definition to be "An intended audience, i.e. a group for whom something was created." rather than use "item" or "subject" to refer to the thing that has the audience. Also "an" rather than "the" since the property is repeatable.

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