Story Henry wrote:
On 10 Jun 2010, at 17:24, Nathan wrote:
Here's a common example of what I'm referring to, suppose we have a (foaf)
documenthttp://ex.org/bobsmith which includes the following triples:
:me foaf:knows <http://example.org/joe_bloggs#me> .
<http://example.org/joe_bloggs#me> a foaf:Person ;
foaf:name "Joe Bloggs"@en .
This is ok by me. Adding more information is useful, as
mentioned as it helps reduce connections. If you had a 1000
in your foaf file without any information, your client would
need to make 1000 calls to get the info.
In all honesty, I'd probably not use a client that showed me 1000
connections at a time, paging is vital when displaying information to
humans so as to prevent information overload - caveat that as soon as
you include 'order by' clauses to the view then all that dereferencing
comes back in to play..
Pragmatically there is no need to make a big fuss about this.
Concur, no need for a big fuss, personally feel it was worth a quick bit
of open discussion and consideration so we don't blindly fall in to
certain patterns without first considering the future effects, namely
the discussion we're having now.
People add what they want. If what they do goes out of date, then
people will notice this.
Your task as a UI designer is to allow people to
1. see where the information came from
2. remove information from graphs they don't trust
Like sig.ma. But if you don't crawl the whole web, you will get
a much better effect.
sig.ma and related are very different use cases to the common (in the
future) use-case though, typical web applications will have no need to
display 'all' the related information, just the information that is
worth considering under the context in which the human is considering
the data, so the amount of dereferencing that needs done will be
somewhat smaller.
Resources that make claims about other people that keeps changing,
will be a nussance and avoided. So there will be social pressure to
get that right.
Yes, fully agree, and another angle to give consideration :)
Best,
Nathan
