Re: Socialnetworks of a person or organization

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