- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 08 Nov 2013 04:49:35 -0800
- To: public-vocabs@w3.org
On 11/8/13 1:47 AM, Yves Raimond wrote: >> > > 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. There actually is an active proposal to modify some definitions of terms to make them broader than they originally were (in the area of Offer).[1] These changes are minor semantic changes compared to the two possibilities we have seen for schema:area, and should not change the meaning of any existing markup. If a term has been defined for a specific use in a meaningful way, broadening it may actually be detrimental to some existing coded data. Plus, the effort to make such a change is not trivial. Although your suggestion is interesting, I'm not sure it is practical in the schema environment. kc [1] http://www.w3.org/community/schemabibex/wiki/Broaden_Offer_usage > > 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. > ----------------------------- > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Received on Friday, 8 November 2013 12:50:05 UTC