Re: Updated LOD Cloud Diagram - First draft and last feedback.
Hi Kingsley, Done. [1] http://bit.ly/vapor-report-on-linked-data-describing-anastasia-dimou Thanks, that's great! Ruben
Re: Updated LOD Cloud Diagram - First draft and last feedback.
On 8/17/14 1:14 PM, Kingsley Idehen wrote: On 8/16/14 2:19 PM, Ruben Verborgh wrote: Hi Kingsley, The issues arise from the conclusions. But I don't really see issues on Vapour. Where did you find them? There is an aspect to Vapour's conclusions that we need to make a little clearer. Basically, this is an assessment of the denotation and connotation discerned from processing the URIs in question. Note, there is an option that indicates use of RDF to make sense of the HTTP URIs it processes (the option I used in my report). Basically, the denotation (name) aspect of the term isn't associated with its connotation (description document), via a discernible RDF relation. Yes it is: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou dcterms:subject http://data.mmlab.be/people/Anastasia+Dimou. Aha! So we can solve this easily, the inference rules used by vapour simply need to include this particular relation. Hence output such as: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou denotes a Web document bearing JSON-LD content. No, it denotes a Web document; one of its possible representations is in JSON-LD format, but there are others (HTML, Turtle). ## Assuming the document describes a single term http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou foaf:primaryTopic http://data.mmlab.be/people/Anastasia+Dimou . Is dcterms:subject enough? Yes it is, absolutely! I'll have that added to our Vapour implementation. Ruben, Done. [1] http://bit.ly/vapor-report-on-linked-data-describing-anastasia-dimou -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: Updated LOD Cloud Diagram - First draft and last feedback.
On 8/16/14 2:19 PM, Ruben Verborgh wrote: Hi Kingsley, The issues arise from the conclusions. But I don't really see issues on Vapour. Where did you find them? There is an aspect to Vapour's conclusions that we need to make a little clearer. Basically, this is an assessment of the denotation and connotation discerned from processing the URIs in question. Note, there is an option that indicates use of RDF to make sense of the HTTP URIs it processes (the option I used in my report). Basically, the denotation (name) aspect of the term isn't associated with its connotation (description document), via a discernible RDF relation. Yes it is: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou dcterms:subject http://data.mmlab.be/people/Anastasia+Dimou. Aha! So we can solve this easily, the inference rules used by vapour simply need to include this particular relation. Hence output such as: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou denotes a Web document bearing JSON-LD content. No, it denotes a Web document; one of its possible representations is in JSON-LD format, but there are others (HTML, Turtle). ## Assuming the document describes a single term http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou foaf:primaryTopic http://data.mmlab.be/people/Anastasia+Dimou . Is dcterms:subject enough? Yes it is, absolutely! I'll have that added to our Vapour implementation. Kingsley Best, Ruben [2] http://linkeddata.uriburner.com/c/9DQHQJ4L - actual description of Anastasia Dimou Since when does my colleague have a stylesheet? ;-) -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: Updated LOD Cloud Diagram - First draft and last feedback.
On 8/15/14 9:31 PM, Ruben Verborgh wrote: Hi Kingsley, I passedhttp://data.mmlab.be/people/Anastasia+Dimou through our edition of Vapour [1] Thanks for checking this. Below is what happens on HTTP level. Looks fine to me. Do you spot an issue here? $ curl -H Accept: text/turtle -Lhttp://data.mmlab.be/people/Anastasia+Dimou -i HTTP/1.1 303 See Other Server: nginx/1.1.19 Date: Fri, 15 Aug 2014 20:25:52 GMT Transfer-Encoding: chunked Connection: keep-alive Cache-Control: public, max-age=3600 Vary: Accept Access-Control-Allow-Origin: * X-Powered-By: Linked Data Fragments Server Location:http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou HTTP/1.1 200 OK Server: nginx/1.1.19 Date: Fri, 15 Aug 2014 20:25:52 GMT Content-Type: text/turtle;charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Vary: Accept-Encoding Cache-Control: public, max-age=3600 Vary: Accept Access-Control-Allow-Origin: * X-Powered-By: Linked Data Fragments Server and it produced an unexpected result [2] The result seems fine to me: Dereferencing Entity URI (requesting (X)HTML) 3/3 Dereferencing Entity URI (requesting JSON-LD) 5/5 Dereferencing Entity URI (requesting RDF/XML) 2/3 Dereferencing Entity URI (requesting TURTLE)5/5 Dereferencing Entity URI (without content negotiation) 2/2 All test that should pass, pass. (We don't offer XML.) i.e., unambiguous names resolve to description documents i.e., as exemplified by terms [3] in natural language, an identifier resolves to the description of its referent. That's what we do, right? -http://data.mmlab.be/people/Anastasia+Dimou is the term -http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou is the document about that term In the worst case, we'll fix any anomalies in our Vapour implementation. Looks fine to me. Did something change in the meantime? The issues arise from the conclusions. Basically, the denotation (name) aspect of the term isn't associated with its connotation (description document), via a discernible RDF relation. Hence output such as: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou denotes a Web document bearing JSON-LD content. You can fix this by adding a relation that associate http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou with http://data.mmlab.be/people/Anastasia+Dimou . Suggestions: ## Assuming the document describes a single term http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou foaf:primaryTopic http://data.mmlab.be/people/Anastasia+Dimou . ## Assuming the document describes a variety of termss http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou foaf:topic http://data.mmlab.be/people/Anastasia+Dimou . ## More IANA friendly http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou xhv:describes http://data.mmlab.be/people/Anastasia+Dimou . ## Powder exploitation http://data.mmlab.be/people/Anastasia+Dimou wdrs:described by http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou. Via URIBurner [1][2] what you have works, due to the fact that we post process the description document and then inject missing relations to alleviate the issue highlighted in this thread. Hope this clarifies matters. Links: [1] http://linkeddata.uriburner.com/c/9DQZ6O3L -- document description (note: Anastasia Dimou is denoted by a URI [confined to @href attribute of a/] that's used as the object of the foaf:topic relation) [2] http://linkeddata.uriburner.com/c/9DQHQJ4L - actual description of Anastasia Dimou [3] http://linkeddata.uriburner.com/c/9BQOSMMQ -- reified statement representing familyName relation . -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: Updated LOD Cloud Diagram - First draft and last feedback.
Hi Kingsley, The issues arise from the conclusions. But I don't really see issues on Vapour. Where did you find them? Basically, the denotation (name) aspect of the term isn't associated with its connotation (description document), via a discernible RDF relation. Yes it is: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou dcterms:subject http://data.mmlab.be/people/Anastasia+Dimou. Hence output such as: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou denotes a Web document bearing JSON-LD content. No, it denotes a Web document; one of its possible representations is in JSON-LD format, but there are others (HTML, Turtle). ## Assuming the document describes a single term http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou foaf:primaryTopic http://data.mmlab.be/people/Anastasia+Dimou . Is dcterms:subject enough? Best, Ruben [2] http://linkeddata.uriburner.com/c/9DQHQJ4L - actual description of Anastasia Dimou Since when does my colleague have a stylesheet? ;-)
Re: Updated LOD Cloud Diagram - First draft and last feedback.
Hi, Thank you for updating the diagram. I would like to add the following dataset. Web NDL Authorities http://datahub.io/en/dataset/national-diet-library-authorities When the dataset was included in the 2011 versions of the LOD Cloud diagram, it was categorized as publications instead of government. This dataset is included in these tables, though not included in Not crawlable table. http://data.dws.informatik.uni-mannheim.de/lodcloud/2014/ISWC-RDB/#toc3 I wonder why this dataset is not included in the updated diagram and I don't know what to do. So, if possible, I would like to add the dataset as publications category to the new version of the diagram, because it is interlinked with VIAF, whose category is publications. Thank you for your cooperation. --- YOKO Shibata National Diet Library, Japan e-mail:yshib...@ndl.go.jp (2014/08/15 16:07), Christian Bizer wrote: Hi all, on July 24th, we published a Linked Open Data (LOD) Cloud diagram containing crawlable linked datasets and asked the community to point us at further datasets that our crawler has missed [1]. Lots of thanks to everybody that did respond to our call and did enter missing datasets into the DataHub catalog [2]. Based on your feedback, we have now drawn a draft version of the LOD cloud containing: 1. the datasets that our crawler discovered 2. the datasets that did not allow crawling 3. the datasets you pointed us at. The new version of the cloud altogether contains 558 linked datasets which are connected by altogether 2883 link sets. As we were pointed at quite a number of linguistic datasets [3], we added linguistic data as a new category to the diagram. The current draft version of the LOD Cloud diagram is found at: http://data.dws.informatik.uni-mannheim.de/lodcloud/2014/ISWC-RDB/extendedLO DCloud/extendedCloud.png Please note that we only included datasets that are accessible via dereferencable URIs and are interlinked with other datasets. It would be great if you could check if we correctly included your datasets into the diagram and whether we missed some link sets pointing from your datasets to other datasets. If we did miss something, it would be great if you could point us at what we have missed and update your entry in the DataHub catalog [2] accordingly. Please send us feedback until August 20th. Afterwards, we will finalize the diagram and publish the final August 2014 version. Cheers, Chris, Max and Heiko -- Prof. Dr. Christian Bizer Data and Web Science Research Group Universität Mannheim, Germany ch...@informatik.uni-mannheim.de www.bizer.de
Re: Updated LOD Cloud Diagram - First draft and last feedback.
On 8/15/14 9:43 AM, Yoko SHIBATA wrote:
Hi,
Thank you for updating the diagram.
I would like to add the following dataset.
Web NDL Authorities
http://datahub.io/en/dataset/national-diet-library-authorities
When the dataset was included in the 2011 versions of the LOD Cloud
diagram, it was categorized as publications instead of government.
This dataset is included in these tables, though not included in Not
crawlable table.
http://data.dws.informatik.uni-mannheim.de/lodcloud/2014/ISWC-RDB/#toc3
I wonder why this dataset is not included in the updated diagram and I
don't know what to do.
So, if possible, I would like to add the dataset as publications
category to the new version of the diagram, because it is interlinked
with VIAF, whose category is publications.
Hi Yoko,
Bearing in mind
http://id.ndl.go.jp/auth/ndla/?query=select+*+where+%7B%3Fs+%3Fp+%3Fo%7D+limit+10output=htmltab
.
Do you have a SPARQL endpoint that supports the SPARQL Query Protocol?
If so, what should I put into this SPARQL-FED query template:
SELECT DISTINCT ?Entity
WHERE {SERVICE {sparql-endpoint-uri}
{SELECT *
WHERE { ?Entity ?Relation ?EntityType} limit 50
}
}
I assume:
SELECT DISTINCT ?Entity
WHERE {SERVICE http://id.ndl.go.jp/auth/ndla
{SELECT *
WHERE { ?Entity ?Relation ?EntityType} limit 50
}
}
--
Regards,
Kingsley Idehen
Founder CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Updated LOD Cloud Diagram - First draft and last feedback.
Feedback: Awesome, just awesome - no “but”s. I was wondering, if not even doubtful, that the next versions would be useful, because there would be so much. This version is actually possibly more useful than previous ones. Not so much for finding datasets, although it is good for that; in addition, at a distance it gives you a real sense of the different sectors, and how they are connected, while the inter-sector connections are visualised. Of course it helps I have a 30” screen, so I can even read the words while looking at the whole picture, and without my glasses :-) It makes me think that perhaps I was right, and sameAs.org would have spoilt it:- we’ll see next time, I guess. Well done team! On 15 Aug 2014, at 08:07, Christian Bizer ch...@bizer.de wrote: Hi all, on July 24th, we published a Linked Open Data (LOD) Cloud diagram containing crawlable linked datasets and asked the community to point us at further datasets that our crawler has missed [1]. Lots of thanks to everybody that did respond to our call and did enter missing datasets into the DataHub catalog [2]. Based on your feedback, we have now drawn a draft version of the LOD cloud containing: 1.the datasets that our crawler discovered 2.the datasets that did not allow crawling 3.the datasets you pointed us at. The new version of the cloud altogether contains 558 linked datasets which are connected by altogether 2883 link sets. As we were pointed at quite a number of linguistic datasets [3], we added linguistic data as a new category to the diagram. The current draft version of the LOD Cloud diagram is found at: http://data.dws.informatik.uni-mannheim.de/lodcloud/2014/ISWC-RDB/extendedLO DCloud/extendedCloud.png Please note that we only included datasets that are accessible via dereferencable URIs and are interlinked with other datasets. It would be great if you could check if we correctly included your datasets into the diagram and whether we missed some link sets pointing from your datasets to other datasets. If we did miss something, it would be great if you could point us at what we have missed and update your entry in the DataHub catalog [2] accordingly. Please send us feedback until August 20th. Afterwards, we will finalize the diagram and publish the final August 2014 version. Cheers, Chris, Max and Heiko -- Prof. Dr. Christian Bizer Data and Web Science Research Group Universität Mannheim, Germany ch...@informatik.uni-mannheim.de www.bizer.de -- Hugh Glaser 20 Portchester Rise Eastleigh SO50 4QS Mobile: +44 75 9533 4155, Home: +44 23 8061 5652
Re: Updated LOD Cloud Diagram - First draft and last feedback.
Hi Kingsley,
Thank you for your reply.
Do you have a SPARQL endpoint that supports the SPARQL Query Protocol?
Yes.
You are right that its SPARQL Endpoin is http://id.ndl.go.jp/auth/ndla.
The below is its SPARQL API Speci cation in English, for your information.
http://iss.ndl.go.jp/ndla/wp-content/uploads/2014/03/api-spec-en.pdf
Best regards,
Yoko
--
YOKO Shibata
National Diet Library, Japan
email:yshib...@ndl.go.jp
(2014/08/15 18:20), Kingsley Idehen wrote:
On 8/15/14 9:43 AM, Yoko SHIBATA wrote:
Hi,
Thank you for updating the diagram.
I would like to add the following dataset.
Web NDL Authorities
http://datahub.io/en/dataset/national-diet-library-authorities
When the dataset was included in the 2011 versions of the LOD Cloud
diagram, it was categorized as publications instead of government.
This dataset is included in these tables, though not included in Not
crawlable table.
http://data.dws.informatik.uni-mannheim.de/lodcloud/2014/ISWC-RDB/#toc3
I wonder why this dataset is not included in the updated diagram and I
don't know what to do.
So, if possible, I would like to add the dataset as publications
category to the new version of the diagram, because it is interlinked
with VIAF, whose category is publications.
Hi Yoko,
Bearing in mind
http://id.ndl.go.jp/auth/ndla/?query=select+*+where+%7B%3Fs+%3Fp+%3Fo%7D+limit+10output=htmltab
.
Do you have a SPARQL endpoint that supports the SPARQL Query Protocol?
If so, what should I put into this SPARQL-FED query template:
SELECT DISTINCT ?Entity
WHERE {SERVICE {sparql-endpoint-uri}
{SELECT *
WHERE { ?Entity ?Relation ?EntityType} limit 50
}
}
I assume:
SELECT DISTINCT ?Entity
WHERE {SERVICE http://id.ndl.go.jp/auth/ndla
{SELECT *
WHERE { ?Entity ?Relation ?EntityType} limit 50
}
}
Re: Updated LOD Cloud Diagram - First draft and last feedback. - sameAs.org
Hi Hugh, thank you very much for your positive feedback. Yes, we decided not to include sameAs.org as we understand it to be more a service that works on top of the LOD cloud than an actual dataset that contributes additional data to the cloud. We hope that this interpretation is OK with you. Cheers, Chris -Ursprüngliche Nachricht- Von: Hugh Glaser [mailto:h...@glasers.org] Gesendet: Freitag, 15. August 2014 11:57 An: Christian Bizer Cc: public-lod@w3.org Betreff: Re: Updated LOD Cloud Diagram - First draft and last feedback. Feedback: Awesome, just awesome - no buts. I was wondering, if not even doubtful, that the next versions would be useful, because there would be so much. This version is actually possibly more useful than previous ones. Not so much for finding datasets, although it is good for that; in addition, at a distance it gives you a real sense of the different sectors, and how they are connected, while the inter-sector connections are visualised. Of course it helps I have a 30 screen, so I can even read the words while looking at the whole picture, and without my glasses :-) It makes me think that perhaps I was right, and sameAs.org would have spoilt it:- well see next time, I guess. Well done team! On 15 Aug 2014, at 08:07, Christian Bizer ch...@bizer.de wrote: Hi all, on July 24th, we published a Linked Open Data (LOD) Cloud diagram containing crawlable linked datasets and asked the community to point us at further datasets that our crawler has missed [1]. Lots of thanks to everybody that did respond to our call and did enter missing datasets into the DataHub catalog [2]. Based on your feedback, we have now drawn a draft version of the LOD cloud containing: 1.the datasets that our crawler discovered 2.the datasets that did not allow crawling 3.the datasets you pointed us at. The new version of the cloud altogether contains 558 linked datasets which are connected by altogether 2883 link sets. As we were pointed at quite a number of linguistic datasets [3], we added linguistic data as a new category to the diagram. The current draft version of the LOD Cloud diagram is found at: http://data.dws.informatik.uni-mannheim.de/lodcloud/2014/ISWC-RDB/exte ndedLO DCloud/extendedCloud.png Please note that we only included datasets that are accessible via dereferencable URIs and are interlinked with other datasets. It would be great if you could check if we correctly included your datasets into the diagram and whether we missed some link sets pointing from your datasets to other datasets. If we did miss something, it would be great if you could point us at what we have missed and update your entry in the DataHub catalog [2] accordingly. Please send us feedback until August 20th. Afterwards, we will finalize the diagram and publish the final August 2014 version. Cheers, Chris, Max and Heiko -- Prof. Dr. Christian Bizer Data and Web Science Research Group Universität Mannheim, Germany ch...@informatik.uni-mannheim.de www.bizer.de -- Hugh Glaser 20 Portchester Rise Eastleigh SO50 4QS Mobile: +44 75 9533 4155, Home: +44 23 8061 5652
Re: Updated LOD Cloud Diagram - First draft and last feedback. - sameAs.org
Hi Chris, On 15 Aug 2014, at 11:15, Christian Bizer ch...@bizer.de wrote: Hi Hugh, thank you very much for your positive feedback. Richly deserved. Yes, we decided not to include sameAs.org as we understand it to be more a service that works on top of the LOD cloud than an actual dataset that contributes additional data to the cloud. We hope that this interpretation is OK with you. It is certainly OK leaving it out. But I don’t agree it does not contribute additional data to the cloud. It publishes millions of triples that are not available (all the inferred sameAs triples), and they would be very hard for people to construct themselves, as they are cross-domain. It also bridges gaps between different equivalence predicates - although of course some people won’t want that! In that sense the main sameAs.org store is a search engine, and provides discovery that would be practically impossible to do any other way. Anyway, encouraged by Kingsley ( :-) ), I have opened all the sameAs sites up to LDSpider:- so next time the crawl is likely to get a load of them. We’ll get to see what it looks like! Best Hugh Cheers, Chris -Ursprüngliche Nachricht- Von: Hugh Glaser [mailto:h...@glasers.org] Gesendet: Freitag, 15. August 2014 11:57 An: Christian Bizer Cc: public-lod@w3.org Betreff: Re: Updated LOD Cloud Diagram - First draft and last feedback. Feedback: Awesome, just awesome - no “but”s. I was wondering, if not even doubtful, that the next versions would be useful, because there would be so much. This version is actually possibly more useful than previous ones. Not so much for finding datasets, although it is good for that; in addition, at a distance it gives you a real sense of the different sectors, and how they are connected, while the inter-sector connections are visualised. Of course it helps I have a 30” screen, so I can even read the words while looking at the whole picture, and without my glasses :-) It makes me think that perhaps I was right, and sameAs.org would have spoilt it:- we’ll see next time, I guess. Well done team! On 15 Aug 2014, at 08:07, Christian Bizer ch...@bizer.de wrote: Hi all, on July 24th, we published a Linked Open Data (LOD) Cloud diagram containing crawlable linked datasets and asked the community to point us at further datasets that our crawler has missed [1]. Lots of thanks to everybody that did respond to our call and did enter missing datasets into the DataHub catalog [2]. Based on your feedback, we have now drawn a draft version of the LOD cloud containing: 1. the datasets that our crawler discovered 2. the datasets that did not allow crawling 3. the datasets you pointed us at. The new version of the cloud altogether contains 558 linked datasets which are connected by altogether 2883 link sets. As we were pointed at quite a number of linguistic datasets [3], we added linguistic data as a new category to the diagram. The current draft version of the LOD Cloud diagram is found at: http://data.dws.informatik.uni-mannheim.de/lodcloud/2014/ISWC-RDB/exte ndedLO DCloud/extendedCloud.png Please note that we only included datasets that are accessible via dereferencable URIs and are interlinked with other datasets. It would be great if you could check if we correctly included your datasets into the diagram and whether we missed some link sets pointing from your datasets to other datasets. If we did miss something, it would be great if you could point us at what we have missed and update your entry in the DataHub catalog [2] accordingly. Please send us feedback until August 20th. Afterwards, we will finalize the diagram and publish the final August 2014 version. Cheers, Chris, Max and Heiko -- Prof. Dr. Christian Bizer Data and Web Science Research Group Universität Mannheim, Germany ch...@informatik.uni-mannheim.de www.bizer.de -- Hugh Glaser 20 Portchester Rise Eastleigh SO50 4QS Mobile: +44 75 9533 4155, Home: +44 23 8061 5652 -- Hugh Glaser 20 Portchester Rise Eastleigh SO50 4QS Mobile: +44 75 9533 4155, Home: +44 23 8061 5652
Re: Updated LOD Cloud Diagram - First draft and last feedback.
Hi Chris, If we did miss something, it would be great if you could point us at what we have missed and update your entry in the DataHub catalog [2] accordingly. Is it possible that our MMLab dataset was not added yet? http://datahub.io/dataset/multimedia-lab We sent it to you on August 4th, but I can't find it in the “publications” category. We meet the requirements of 1) dereferenceable URIs and 2) at least 50 RDF links pointing at other datasets. For example, here is a dereferenceable URI: - http://data.mmlab.be/people/Anastasia+Dimou And here are sameAs links to other datasets: - http://data.mmlab.be/mmlab?predicate=owl%3AsameAs We would be most happy if you would consider adding our dataset. Thanks, Ruben
Re: Updated LOD Cloud Diagram - First draft and last feedback.
On 8/15/14 4:04 PM, Ruben Verborgh wrote: Hi Chris, If we did miss something, it would be great if you could point us at what we have missed and update your entry in the DataHub catalog [2] accordingly. Is it possible that our MMLab dataset was not added yet? http://datahub.io/dataset/multimedia-lab We sent it to you on August 4th, but I can't find it in the “publications” category. We meet the requirements of 1) dereferenceable URIs and 2) at least 50 RDF links pointing at other datasets. For example, here is a dereferenceable URI: -http://data.mmlab.be/people/Anastasia+Dimou And here are sameAs links to other datasets: -http://data.mmlab.be/mmlab?predicate=owl%3AsameAs We would be most happy if you would consider adding our dataset. Thanks, Ruben Ruben, I passed http://data.mmlab.be/people/Anastasia+Dimou through our edition of Vapour [1] and it produced an unexpected result [2], in regards to Linked Open Data principles i.e., unambiguous names resolve to description documents i.e., as exemplified by terms [3] in natural language, an identifier resolves to the description of its referent. Hopefully, this will shed light on a range of orthogonal matters related to nailing down what Linked Open Data is about etc.. In the worst case, we'll fix any anomalies in our Vapour implementation. Links: [1] http://linkeddata.uriburner.com:8000/vapour -- our rendition of Vapour that in includes RDF semantics based reasoning (it uses RDF semantics to handled entity denotation and connotation) [2] http://bit.ly/1rdzdRj -- Current Vapour Report [3] http://www.wikihow.com/Differentiate-Between-a-Term-and-a-Word -- difference between a word (RDF IRI) and term (RDF based Linked Data HTTP URI). -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: Updated LOD Cloud Diagram - First draft and last feedback.
Hi Kingsley, I passed http://data.mmlab.be/people/Anastasia+Dimou through our edition of Vapour [1] Thanks for checking this. Below is what happens on HTTP level. Looks fine to me. Do you spot an issue here? $ curl -H Accept: text/turtle -L http://data.mmlab.be/people/Anastasia+Dimou -i HTTP/1.1 303 See Other Server: nginx/1.1.19 Date: Fri, 15 Aug 2014 20:25:52 GMT Transfer-Encoding: chunked Connection: keep-alive Cache-Control: public, max-age=3600 Vary: Accept Access-Control-Allow-Origin: * X-Powered-By: Linked Data Fragments Server Location: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou HTTP/1.1 200 OK Server: nginx/1.1.19 Date: Fri, 15 Aug 2014 20:25:52 GMT Content-Type: text/turtle;charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Vary: Accept-Encoding Cache-Control: public, max-age=3600 Vary: Accept Access-Control-Allow-Origin: * X-Powered-By: Linked Data Fragments Server and it produced an unexpected result [2] The result seems fine to me: Dereferencing Entity URI (requesting (X)HTML) 3/3 Dereferencing Entity URI (requesting JSON-LD) 5/5 Dereferencing Entity URI (requesting RDF/XML) 2/3 Dereferencing Entity URI (requesting TURTLE)5/5 Dereferencing Entity URI (without content negotiation) 2/2 All test that should pass, pass. (We don't offer XML.) i.e., unambiguous names resolve to description documents i.e., as exemplified by terms [3] in natural language, an identifier resolves to the description of its referent. That's what we do, right? - http://data.mmlab.be/people/Anastasia+Dimou is the term - http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou is the document about that term In the worst case, we'll fix any anomalies in our Vapour implementation. Looks fine to me. Did something change in the meantime? Ruben
