Jiří Procházka wrote:
Hi Nathan,

origin of this pattern is from RDF - graph is just a piece of paper
where you can write any statements...

But I understand - your view of Linked Data is much different,
introducing more complex notions of things and their descriptions in
which it is desirable, after getting a description, to identify the role
which statements relating other things play.

I see that someone could want to express statements which relate to the
described thing - make sense from the point of view of its description
but not being in the description received by dereferencing URIs of the
subject/object of the statement or even contradicting it, perhaps maybe
when in doubt of their future.

Other than that I see it bad practice, because of the reasons you
explained (out of date possibility being the most important).
I believe Linked Data encourages dereferencing.
What Linked Data brings into the Semantic Web puzzle is a recommended
algorithm how to get data (follow your nose?) and maybe that is the
thing you really are looking for...

Indeed :)

I wonder if there is a need for vocabulary allowing people describe
recommendations of URIs to surely dereference, or perhaps measurement of
URI importance in the graph, feeding a more complex algorithm...

I'd suggest that this may not be a good idea (although I've considered and suggest similar countless times myself) - there is no way to infer what direction somebody will be looking at your links, or what information people may be interested; it's entirely context specific - I guess even if you were to give hints that X related document contained information primarily of type Y, then this could itself be an anti-pattern, the only true way to get the big picture and all the information, is to do just that, 'GET' all the information.

At the back of my mind, there is a small realisation that the sooner we (as a community) start designing our data in a way that encourages dereferencing, the sooner we'll start doing more dereferencing ourselves - which will soon bring to the fore all the important issues such as http caching, providing granular access to data, and related :)

Best,

Nathan

Regards,
Jiri Prochazka


On 06/10/2010 05:24 PM, Nathan wrote:
All,

Here's a common example of what I'm referring to, suppose we have a
(foaf) document http://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 .

In Linked Data terms one could suggest that the description of Joe
Bloggs doesn't 'belong' in this document (although clearly it can be here).

I can quite easily see how trend came about, there are benefits, it's
both an optimisation method (saves dereferencing) and it's an inclusion
of human presentable information (which aids display / comprehension in
'foaf viewers').

However, there are drawbacks too, the data could easily go out of date /
out of sync, it's not dereferencable (the adverse effects in this
example aren't specifically clear, but in other use-cases they are
considerable).

Over and above these simple thoughts, I'm quite sure that there are
bigger architectural and best practise considerations (for a web of
data), for example:

 - does this create an environment where we are encouraged not to
deference linked data (or where it is common to look local first)

 - does this point to bigger issues such as not having a single global
predicate for a default human presentable 'name' for all things that can
be 'named' (given a URI) - even though many candidates are available.

 - should 'reading ahead' (dereferencing all linked data before
presentation to a user / trying to glean an understanding) be encouraged
over providing a limited local subset of the data which could easily be
inaccurate or out of date.

 - is there an gut instinct in the community that most data will
ultimately end up being presented to a human somewhere along the line,
and this is driving us to make such design decisions.

Any thoughts or strong feelings on the issue(s)? and is anybody aware of
whether this practise came about more by accident than by design?

Best,

Nathan




Reply via email to