- From: Jiří Procházka <ojirio@gmail.com>
- Date: Thu, 10 Jun 2010 23:59:50 +0200
- To: nathan@webr3.org
- CC: Linked Data community <public-lod@w3.org>
- Message-ID: <4C116056.7020408@gmail.com>
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