W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: clarification on the use of fragments

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Wed, 10 Nov 2010 16:08:27 -0500
Message-ID: <AANLkTi=WRB5xmhSo8=Q32P9K6OQD1bCTu7WTniw46_-b@mail.gmail.com>
To: nathan@webr3.org
Cc: Linked Data community <public-lod@w3.org>
In the interest of clarification, the reason that some of us advocate
*not* putting several resources in one file using fragments is that it
then becomes difficult to serve (standard web) pages that give only
information about one resource, because the server doesn't see the
fragment id. This may be only a minor frustration in cases where only
a handful of resources are described in a single file, but is
devastating when the resource contains many. For example I work with
the NCBI Taxonomy, which currently names species using the fragid. As
the file is > 200M you can imagine that it hurts when I put such a URI
into my browser and all 200+M starts coming back.


On Wed, Nov 10, 2010 at 3:43 PM, Nathan <nathan@webr3.org> wrote:
> All,
> For some reason I keep hearing people inferring that if you use fragments
> you must for some reason put all your descriptions of things / resources in
> a single "file".
> I'd just like to confirm that couldn't be further from the truth if it
> tried.
> /resources/Foo
> /resources/Bar
> /resources/Baz
> /Foo#t
> /Bar#t
> /Baz#t
> However, with #fragments you can *optionally* put the description of one or
> more "things" in a single "file"
> /things#foo
> /things#bar
> /Baz#t
> Fragments allow you to be as verbose or as terse as you like with your data.
> This is particularly useful for logically grouping related resources, for
> instance in ones FOAF profile you may have:
> /bob#me
> /bob#certificate
> /bob#assistant
> But you most certainly are not constrained to putting the descriptions of
> all your things in one "file", that's about as ridiculous as it sounds.
> Best,
> Nathan
Received on Wednesday, 10 November 2010 21:09:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC