- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Sun, 04 May 2014 17:01:17 -0700
- To: Guha <guha@google.com>
- CC: Markus Lanthaler <markus.lanthaler@gmx.net>, W3C Web Schemas Task Force <public-vocabs@w3.org>
On 05/04/2014 12:57 PM, Guha wrote: > -1 -1 to what part of Markus's comment? That there are large parts of schema.org whose use to data providers is unsubstantiated? That it would be easier to convince data providers to mark up in JSON? That there are no significant benefits in Martin's approach beyond what would be provided by some well-crafted JSON? > The problem addressed by Martin Hepp is something schema.org > <http://schema.org> applications at Google face. So, yes, it will find use. Which part of Martin's approach addresses problems encountered within schema.org applications in Google? The ability to overcome some syntactic limitations of microdata? A new way to extend the schema.org ontology using a reserved property and pairs? The value/minValue/maxValue/-/,/valueReference/unitCode/unitText method for presenting unions of values and intervals and other stuff? > guha peter > On Sun, May 4, 2014 at 11:37 AM, Peter F. Patel-Schneider > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote: > > +1 > > On 05/04/2014 01:28 AM, Markus Lanthaler wrote: > > [...] > > > There are already hundreds of concepts defined by schema.org > <http://schema.org>, > yet only a very small fraction of them results in concrete benefits > for the > data *provider*. What's the motivation for them to use this approach? > I bet > it would be much easier to convince them to, e.g., publish their data as > plain-old JSON instead (not JSON-LD). That's extremely cheap and every > programmer is familiar with it. You also get more or less the same > benefits, > i.e., structured data that you claim is easier to interpret than > completely > unstructured, natural language. So why not just embed JSON blocks. In most > programming//templating languages that wouldn't require more than one line > of code. > > > -- > Markus Lanthaler > @markuslanthaler > > > > > >
Received on Monday, 5 May 2014 00:01:48 UTC