Comments on: What to do with Linked Data? http://blog.meresco.org/2010/02/05/what-to-do-with-linked-data/ What happened in the MERESCO community? Tue, 18 May 2010 22:04:18 +0000 hourly 1 http://wordpress.com/ By: Erik J. Groeneveld http://blog.meresco.org/2010/02/05/what-to-do-with-linked-data/#comment-7 Erik J. Groeneveld Fri, 12 Feb 2010 08:09:35 +0000 http://blog.meresco.com/?p=100#comment-7 What @jvanvuuren points out, could that be added as step 7 as: 7. Start using fine grained provenance information? I wasn't clear about the fact that I assume equal authority within your Authority Cloud. For example, when your records contain author URIs and you load author information from an institution you trust, you can just merge the triples. That is what happens today (using other technologies), and you can continue doing so. After some time you will definitely want to distinguish who said what, but by that time, you already have your (RDF) tools in place making making life easier. I got a reply by e-mail from Frits van Latum suggesting this type of graphs for dealing with tags being added to objects. I am posting it here assuming Frits agrees: <a href="http://meresco.files.wordpress.com/2010/02/rdfdiscover.jpg" rel="nofollow"><img class="alignright size-full wp-image-109" title="rdfDiscover" src="http://meresco.files.wordpress.com/2010/02/rdfdiscover.jpg" alt="" width="432" height="134" /></a> What @jvanvuuren points out, could that be added as step 7 as:

7. Start using fine grained provenance information?

I wasn’t clear about the fact that I assume equal authority within your Authority Cloud. For example, when your records contain author URIs and you load author information from an institution you trust, you can just merge the triples. That is what happens today (using other technologies), and you can continue doing so. After some time you will definitely want to distinguish who said what, but by that time, you already have your (RDF) tools in place making making life easier.

I got a reply by e-mail from Frits van Latum suggesting this type of graphs for dealing with tags being added to objects. I am posting it here assuming Frits agrees:

]]> By: jvanvuuren http://blog.meresco.org/2010/02/05/what-to-do-with-linked-data/#comment-6 jvanvuuren Wed, 10 Feb 2010 14:10:37 +0000 http://blog.meresco.com/?p=100#comment-6 As stated a record describes a set of statements about everything (e.g a set of triplets). But apart from the content of a record (e.g. triplets about objects) a record is also implicitly used to define the “source” of the data. If you do not bring this information in the equation you will lose relevant data. This is especially prominent when the triplets are subjective, so in the querying of the data you would like to include characteristics of the “source” of these data (like experience, role, organization) This means that if the source of the record is not defined in the record itself, not only the triplets in a record should be stored, but also the triplets about the record needs to be stored, before you abandon the principle of a “record”. In theory a “record” is just any object as another. In triplet terms you can define “record 5832” contains “triplet 123”. You can also define “record 5832” is supplied by “organization ABC”. This implies that “triplet 123” is supplied by “organization ABC”. Only if the later is stored the object of “record” is not relevant anymore. As stated a record describes a set of statements about everything (e.g a set of triplets). But apart from the content of a record (e.g. triplets about objects) a record is also implicitly used to define the “source” of the data. If you do not bring this information in the equation you will lose relevant data. This is especially prominent when the triplets are subjective, so in the querying of the data you would like to include characteristics of the “source” of these data (like experience, role, organization)

This means that if the source of the record is not defined in the record itself, not only the triplets in a record should be stored, but also the triplets about the record needs to be stored, before you abandon the principle of a “record”.

In theory a “record” is just any object as another. In triplet terms you can define “record 5832” contains “triplet 123”. You can also define “record 5832” is supplied by “organization ABC”. This implies that “triplet 123” is supplied by “organization ABC”. Only if the later is stored the object of “record” is not relevant anymore.

]]> By: Erik J. Groeneveld http://blog.meresco.org/2010/02/05/what-to-do-with-linked-data/#comment-5 Erik J. Groeneveld Mon, 08 Feb 2010 14:17:16 +0000 http://blog.meresco.com/?p=100#comment-5 Thanks for your remark. I assume that with 'resolvable' you mean HTTP+DNS resolvable? If so, I agree that this is important when displaying unresolved statements in a web-browser. This is what is suggested in step 5. If KNAW would have a resolver, say http://info.knaw.nl/, then what would the complete URI look like? Something like http://info.knaw.nl/eu-repo/dai/nl/071792279? When 'resolvable' is limited to resolvable within your own Authority Cloud (up to step 4), which is suggested to be in your triple store, then it would different. Then it may be enough to have harvested DAIs from KNAW/NARCIS and those DAIs will match whether they are HTTP+DNS resolvable or not. This of course depends on the availability of DAI for harvesting. I don't know if there is such a service from KNAW, do you? As a last remark: there are mechanisms in RDF/XML to make abbreviations, such as namespaces and entities. Defining an abbreviation for 'info:' would make the URI resolvabe. This is not intended in the example however. I wanted it to stay as short as possible. Thanks for your remark. I assume that with ‘resolvable’ you mean HTTP+DNS resolvable? If so, I agree that this is important when displaying unresolved statements in a web-browser. This is what is suggested in step 5.

If KNAW would have a resolver, say http://info.knaw.nl/, then what would the complete URI look like? Something like http://info.knaw.nl/eu-repo/dai/nl/071792279?

When ‘resolvable’ is limited to resolvable within your own Authority Cloud (up to step 4), which is suggested to be in your triple store, then it would different. Then it may be enough to have harvested DAIs from KNAW/NARCIS and those DAIs will match whether they are HTTP+DNS resolvable or not.

This of course depends on the availability of DAI for harvesting. I don’t know if there is such a service from KNAW, do you?

As a last remark: there are mechanisms in RDF/XML to make abbreviations, such as namespaces and entities. Defining an abbreviation for ‘info:’ would make the URI resolvabe. This is not intended in the example however. I wanted it to stay as short as possible.

]]> By: thomasplace http://blog.meresco.org/2010/02/05/what-to-do-with-linked-data/#comment-3 thomasplace Sat, 06 Feb 2010 21:31:45 +0000 http://blog.meresco.com/?p=100#comment-3 Interesting contribution. An essential feature of Linked Data is that the URIs are resolvable. This allows for following the links from one URI to other URIs (to go form one node to other nodes). The URI info:eu-repo/dai/nl/071792279 in your example fails in this respect. info URIs are by definition not resolvable which make them unsuitable for Linked Data. When you use info URIs and you want your data to be Linked Data, you must combine them with resolvable URIs and relate the URIs with owl:sameAs. Interesting contribution.
An essential feature of Linked Data is that the URIs are resolvable. This allows for following the links from one URI to other URIs (to go form one node to other nodes). The URI info:eu-repo/dai/nl/071792279 in your example fails in this respect. info URIs are by definition not resolvable which make them unsuitable for Linked Data. When you use info URIs and you want your data to be Linked Data, you must combine them with resolvable URIs and relate the URIs with owl:sameAs.

]]>