Re: status of the TV/Radio proposal

Hello,

On Thu, 2013-11-07 at 13:34 -0800, Karen Coyle wrote:
> Thad, I agree with this as long as the definition fits the broadness of
> the use. So if "area" is defined as something like "general physical
> range of thing or service being described" I'm all for it. Then it is
> reusable in a lot of different contexts. However, if the definition
> specifies that it is the range of a broadcast service, then the term
> also has to be qualified. One can, of course, have both in the
> vocabulary, but I, too, worry that the vocabulary will swell with so
> many specific terms. (As per Martin Hepp's postings on that concern.)
>

One option is to keep schema:area as-is for now, and extend its domain
(and amend the corresponding description) when new use-cases for it
appear.

Best,
Yves

> We have talked here about facets. I think we also may want to look at
> the linguistic implications of Zipf's Law [1], which shows that the most
> frequently used terms are the least semantically specific (and are often
> used in combination with each other, e.g. "solar power"), while highly
> specific terms are used infrequently and are less reusable. That,
> combined with the proven success of Dublin Core as a simple but highly
> flexible vocabulary [2]
>
> kc
> [1] https://en.wikipedia.org/wiki/Zipf%27s_law

> [2] http://kcoyle.blogspot.com/2013/10/dublin-core-usage-in-lod.html

>
> On 11/7/13 11:38 AM, Thad Guidry wrote:
> > I would counter and say... There is a give and take in generalizing
> > schema concepts and terms.
> >
> > An advantage is that "area" can be easily parsed and reused to collect
> > large sets of Things and build a containerized view of them, for say
> > "All Things... Boston"
> >
> > A disadvantage is that mapping between same named properties in
> > schema.org <http://schema.org> currently requires more work for web
> > developers, it is not extremely hard, but it is more work.  (unless I
> > have missed a cool RDF view from Dan of all the properties in schema.org
> > <http://schema.org> aligned by their conceptual "sameAs" meaning ?)
> >
> > Conceptually, how is a "broadcastArea" any different than a
> > "NewspaperCirculationArea" ?  They are not.  The devil is in the
> > details, but the angel sometimes is in the generalization of details
> > like, "area".
> >
> > My opinion is that we should be making it easier for web developers, and
> > promoting reuse, over and over and over again.
> > But long term, I know in reality that reuse might simply be building a
> > better visualization and mapping of similar property meanings to provide
> > developers an easy way to parse and apply automated mappings across many
> > similar properties across all domains in schema.org <http://schema.org>.
> >   A range or "sameAs".   In my long term view, "broadcastArea" and
> > "NewspaperCirculationArea" are the same and both stem from the idea of a
> > range called http://www.schema.org/Place

> >
> >
> > On Thu, Nov 7, 2013 at 12:46 PM, Evain, Jean-Pierre <evain@ebu.ch
> > <mailto:evain@ebu.ch>> wrote:
> >
> >     ALthough I can see the point of Karen, I miss the last point from Peter.
> >
> >     Actually the TVRadio proposal specialise general concepts (series,
> >     season, etc.) of schema.org <http://schema.org>. We are therefore
> >     addressing the point of Karen I believe, unless things have recently
> >     changed.
> >
> >     Jean-Pierre
> >     ________________________________________
> >     From: Peter F. Patel-Schneider [pfpschneider@gmail.com
> >     <mailto:pfpschneider@gmail.com>]
> >     Sent: 07 November 2013 18:56
> >     To: kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>;
> >     public-vocabs@w3.org <mailto:public-vocabs@w3.org>
> >     Subject: Re: status of the TV/Radio proposal
> >
> >     I do agree that general-sounding terms should not be used for specific
> >     notions.  There are lots more such in the proposal, e.g., Series,
> >     Season,
> >     Episode, Clip.
> >
> >     It appears to me that there are several occurrences of this already in
> >     schema.org <http://schema.org>, e.g, the use of Abdomen for physical
> >     medical examination of the
> >     abdomen, Float for floating point number, and object for the thing
> >     acted upon
> >     by an action.
> >
> >     A solution, of course, is to use longer identifiers, e.g.,
> >     areaWithinWhichUsersCanExpectToReachTheBroadcastService.   This can
> >     get rather
> >     unwieldy, however.   An interesting compromise is to use something
> >     like CURIES
> >     http://www.w3.org/TR/curie/ where a long name is abbreviated in a
> >     flexible manner.
> >
> >     peter
> >
> >
> >     On 11/07/2013 09:16 AM, Karen Coyle wrote:
> >      > Can't help you with your question, but a quick glance turned up this:
> >      >
> >      >      Add property 'area', range 'Place'
> >      >
> >      >  with description "the area within which users can expect to
> >     reach the
> >      > BoradcastService"
> >      >
> >      > Lately we've been trying to avoid the addition of general terms (like
> >      > "area") when they're actually representing something more
> >     specific (like
> >      > "area within which users can expect to reach the broadcast
> >     service"). So
> >      > before moving this proposal in, we might want to look at it with
> >     that in mind.
> >      >
> >      > I would suggest "broadcastArea" as a better term, but essentially
> >     I mainly
> >      > care that the general term "area" not be used for this specific
> >     concept.
> >      >
> >      > kc
> >
> >
> >     ------------------------------------------------------------------------------
> >
> >     **************************************************
> >     This email and any files transmitted with it are confidential and
> >     intended solely for the use of the individual or entity to whom they
> >     are addressed.
> >     If you have received this email in error, please notify the system
> >     manager. This footnote also confirms that this email message has
> >     been swept by the mailgateway
> >     **************************************************
> >
> >
> >
> >
> >
> >
> > --
> > -Thad
> > +ThadGuidry <https://www.google.com/+ThadGuidry>
> > Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
>



-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Friday, 8 November 2013 09:47:43 UTC