Re: status of the TV/Radio proposal

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.orgcurrently 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 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.  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> 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. 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]
> Sent: 07 November 2013 18:56
> To: kcoyle@kcoyle.net; 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, 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/>