- From: Dan Brickley <danbri@google.com>
- Date: Fri, 11 Apr 2014 09:28:42 +0100
- To: "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
On 11 April 2014 09:07, martin.hepp@ebusiness-unibw.org <martin.hepp@ebusiness-unibw.org> wrote: > Dan: > I am perfectly fine with your broad notion of linked data ;-) With "all linked data stuff", I meant primarily abandoning the use of two separate slash-based URIs for the type and its page. > > The problem with many Linked Open Data recommendations is that they do e.g. not take into account the enormous amount of traffic caused by the use of HTTP prefetching, particularly by mobile clients and proxies in the infrastructure of mobile service providers. They often try to dereference any URI found in any href attribute, and if that returns an HTTP redirect, this consumes resources. > > What I fear is are attempts to infiltrate the pragmatic, yet groundbreaking and far-reaching approach of schema.org with driving a narrow-minded notion of linked data. Of course, one can use schema.org in such settings (and that should be possible), but we should also be very reluctant with incorporating "narrow" LOD into the fibre of schema.org. "narrow LOD" is a good name for it. There's certainly work that can be done around schema.org to improve its use; a particular area of mutual concern here could be multi-page graphs. Schema.org graphs per-page work pretty well, but joining them across a site is often tricky due to casual URI usage. Finding a useful balance here between webmaster-friendly pragmatism and usable site-wide graph data will be important. Consider e.g. the kind of complex data that BBC programs or MusicBrainz offer. It should be possible to expose that in schema.org without fragmenting the graph. Most high profile tools currently focus on per-page graphs. Dan
Received on Friday, 11 April 2014 08:29:09 UTC