Re: Inclusion of additional (non dereferencable) data?

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

Received on Friday, 11 June 2010 08:38:18 UTC