Re: Inclusion of additional (non dereferencable) data?

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...

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...

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
> 

Received on Thursday, 10 June 2010 22:00:24 UTC