Re: Mediatypes that map to application/ld+json with a profile
Hi Sarven, Phil, Rob, > Are there mediatypes that map to application/ld+json with a profile? This begs the question why one would want to do that. The problem with specific MIME types is that they are only one-dimensional. What if multiple dimensions have to be considered? What if I want an activity represented in RDF, but not in JSON-LD? Do we need things like application/activity+turtle or +xml? That doesn't scale… Why would we want to have such specific media types when we already have media types for RDF syntaxes? After all, the whole idea of RDF data is that it is self-descriptive; that a client can understand that a document contains an activity / person / building by interpreting it. application/activity+json should be totally unnecessary. Note that there is currently no official interpretation of the + token, so a client cannot even assume application/xxx+json is a JSON(-LD) document. Clients have to he hard-coded for application/activity+json. This defeats much of the purpose of RDF. >> Format/serialisation/Mime Type, whatever, is not enough. You need to >> know the profile. Erik Wilde has an internet draft on this [1] too. I definitely think profiles are the way to go. >> Should we also consider it as another dimension of content negotiation? Definitely. That's the only use case I see for application/activity+json-ish things, telling a server that you expect a certain vocabulary / profile. So I'd expect a client to say Accept: text/turtle;profile="http://example.org/activity; instead. >>> The Web Annotation WG decided /not/ to do this, and to only use a profile. >>> So the media type for the JSON-LD annotation serialization is: >>> application/ld+json;profile="http://www.w3.org/ns/anno.jsonld; I love it; that's the most scalable way to do this, and it does justice to what RDF stands for: the interpretation is inside of the message. How is it actually implemented? It should be sufficient that the client does Accept: application/ld+json;profile="http://www.w3.org/ns/anno.jsonld; and the server only says Content-Type: application/ld+json since the rest would be in the message. Actually, the client should also be able to say Accept: text/turtle;profile="http://www.w3.org/ns/anno.jsonld; to which the server would reply with Content-Type: text/turtle but I guess the notion of "profile" (RFC 6906) here is to be interpreted more strictly as "JSON-LD profile". I would be interesting to consider Accept: application/ld+json;profile="http://www.w3.org/ns/anno; without any extension, allowing content negotiation on the profile. Best, Ruben PS Wrote more about that here: – http://ruben.verborgh.org/phd/ruben-verborgh-phd.pdf#page=103 – http://ruben.verborgh.org/blog/2015/10/06/turtles-all-the-way-down/
Re: Where are the Linked Data Driven Smart Agents (Bots) ?
HI Krzysztof, > this is all about finding the right balance Definitely—but I have the feeling the balance is currently tipped very much to one side (and perhaps not the side that delivers the most urgent components for the SemWeb). > as we also do not want to have tons of 'ideas' > papers without any substantial content or proof of concept Mere ideas would indeed not be sufficient; but even papers with substantial content and/or a proof of concept will have a difficult time getting accepted if there is no evaluation that satisfies the reviewers. (And, lacking a framework to evaluate evaluations, I see people typically choosing for things they know, hence why incremental research gets accepted easily.) Best, Ruben
Re: Where are the Linked Data Driven Smart Agents (Bots) ?
Hi, This is a very important question for our community, given that smart agents once were an important theme. Actually, the main difference we could bring with the SemWeb is that our clients could be decentralized and actually run on the client side, in contrast to others. One of the main problems I see is how our community (now particularly thinking about the scientific subgroup) receives submissions of novel work. We have evolved into an extremely quantitative-oriented view, where anything that can be measured with numbers is largely favored over anything that cannot. Given that the smart agents / bots field is quite new, we don't know the right evaluation metrics yet. As such, it is hard to publish a paper on this at any of the main venues (ISWC / ESWC / …). This discourages working on such themes. Hence, I see much talent and time going to incremental research, which is easy to evaluate well, but not necessarily as ground-breaking. More than a decade of SemWeb research has mostly brought us intelligent servers, but not yet the intelligent clients we wanted. So perhaps we should phrase the question more broadly: how can we as a community be more open to novel and disruptive technologies? Best, Ruben
federated querying with lightweight interfaces
Dear all, In a recently accepted JWS article [1], we evaluated the Triple Pattern Fragments (TPF) interface in different ways, which includes a federated scenario (FedBench + added complex queries): http://linkeddatafragments.org/publications/jws2016.pdf Especially the performance in the federated scenario proved rather interesting: both for completeness and execution time, the TPF client over the public Internet achieved scores similar to well-known SPARQL federation engines over a closed network within the measured interval of 300 seconds. For some queries, the TPF client achieved better completeness and/or shorter query execution times. Note that the TPF client did _not_ perform a separate source selection step in advance, in contrast to other engines, challenging conventional wisdom about query federation. This is an indicator that lightweight interfaces are more than just an academic exercise. Especially in federated scenarios, which in my opinion show the true value of Linked Data, they can provide a viable and cost-effective solution to publish data— as long as we remain realistic about the kind of queries we expect to yield answers fast. Furthermore, TPF is just one of the many lightweight interfaces we can imagine: several others are possible (some of which are subsets of SPARQL). And if we make interfaces self-describing, as we do with the TPF of interfaces, clients can automatically discover what features servers have, and adapt accordingly. Our results confirm that data does not need to be either a SPARQL endpoint or a dump: even a very limited query interface can deliver promising results in a federated setting. As such, this mail is in the first place a plea for diversity: making querying work on a Web scale can benefit from lightweight interfaces. Best regards, Ruben PS For those who would like to experiment with live federated queries, see: http://bit.ly/swedish-nobel-harvard and http://bit.ly/cubist-works
Re: Deprecating owl:sameAs
Wait, I'm confused. Do you mean that owl:sameSameButDifferent owl:sameSameButDifferent owl:sameAs. ? Best, Ruben
Re: Survey: Use of this list for Calls for Papers
> A simple plain text email works just fine. Plain text works fine for me—it's just that there's too much of it right now. Efficient CfPs that inform people with the least possible amount of words would be an added value to a topic-specific mailing list like this. Some common practices, like listing the whole PC and the conference's excellent reputation are just not helpful. And that is what, I believe, a mailing list should focus on: conveying helpful information to readers. I think it's important to say this in the discussion, because now it's presented as a false dichotomy: either we want CfPs or not. Maybe the more interesting question is: how can we have better CfPs that are actually helpful? Best, Ruben
Re: Survey: Use of this list for Calls for Papers
Dear all, Thanks Phil for bringing up this debate. I agree with Axel about the list being a natural place. However, I think we need something else: a clear guideline for efficient CfPs. Too often, CfPs look like the braindump of 10 different people all mixed together. The more information it contains, the better the sender seems to think it is. Except that it's not. (Not to mention the obligatory apologies on top, which only annoy people more.) If we mail around CfPs, they should be efficient; having a suggested template would really help. As far as I'm concerned, a CfP only contains: – who should submit and why – the title and place – dates (deadline / event) – URL for all info All other details are irrelevant at first. Just 1 screen—no scrolling—instead of 10. By making CfPs more efficient, they also become more useful for readers, and hence much more of an added value to subscribers than they are now. Best, Ruben
Big Linked Data benchmarking survey
** Fill out the Big Linked Data benchmarking survey and WIN Amazon vouchers ** Dear all, Are you working on a solution in the Linked Data Lifecycle, do you require a Linked Data solution or are you innovating the Linked Data Lifecycle? If so, we invite you to answer some questions regarding benchmarking and potential use cases. The survey will take less than five minutes to fill in: http://goo.gl/forms/1iRIoG4Xpb The HOBBIT project (http://project-hobbit.eu/) aims to abolish the barriers to the adoption and deployment of Big Linked Data by providing companies with open benchmarking reports which show the fitness of their solutions. By filling in this survey, you will have a chance at winning one of the Amazon vouchers of a value up to $50, this includes people who already filled in this survey before. The winners will be determined during the HOBBIT community event at ESWC at the end of May. Thank you for your time, Ruben
Big Linked Data Benchmarking Survey
Dear all, HOBBIT [1] aims to abolish the barriers to the adoption and deployment of Big Linked Data by providing companies with open benchmarking reports which show the fitness of their solutions. Are you working on a solution in the Linked Data Lifecycle, do you require a Linked Data solution or are you innovating the Linked Data Lifecycle? If so, we invite you to answer some questions regarding benchmarking and potential use cases. The survey should not take more than five minutes to fill in: http://goo.gl/forms/1iRIoG4Xpb Thank you for your time, Ruben [1] http://project-hobbit.eu/
Re: Announce: Javascript based RDF Editor
Hi Kingsley, This seems great stuff—great you've done this in JavaScript. Would it be possible to have a (restricted) demo live online somewhere? This might make it directly accessible for people who want to test. Best, Ruben
Re: What Happened to the Semantic Web?
Hi Kingsley, While your main points are correct, I disagree with your conclusion. I guess everything depends on what you mean with "The Semantic Web", but if I read the article with that title, we're arguably _not_ there. In that sense, I find it strange you use Google as an example of success. The fact that the big players are doing something with Linked Data, is not necessarily a success, as they have much larger means than most of us. For me, the Semantic Web vision has always been about clients. It's a democratic principle of publishing and consuming data: everyone can say anything about anything, but everyone should also be able to consume that data. At the moment, consuming seems only within reach of the big players, who have the capacity to do it otherwise anyway. In what sense did we succeed then? To me, The Semantic Web is like Google, but then run on my machine. My client that knows my preferences, doesn't share them, but uses them the find information on the Web for me. I still hope to see that. Then, we might be there. Best, Ruben
Re: What Happened to the Semantic Web?
Hi Kingsley, Some valid points. Two quick remarks: >> For me, the Semantic Web vision has always been about clients. > > I think the "Semantic Web" has always been about "The Web" (clients and > servers) :) Of course—but the emphasis in the community has mostly been on servers, whereas the SemWeb vision started from agents (clients) that would do things (using those servers). Now, the Semantic Web is mostly a server thing, which the Google/CSE example also shows. >> At the moment, consuming seems only within reach of the big players, >> who have the capacity to do it otherwise anyway. > > No, you can craft a CSE yourself right now and triangulate searches > scoped to specific entity types. Do you mean making a CSE through the Google interface? But then I'm actually querying the Google servers, not the Web… Then intelligence is with a centralized system, not between clients and servers. Not yet the Semantic Web for me. Best, Ruben
Re: Introducing RASH 0.4
Hi Silvio, > - old elements such "div" and "span" have been replaced by more appropriate > and semantic-oriented elements, e.g., "section", "figure", "figcaption", > "blockquote", "pre" and "code"; I'm happy with this decision. It strikes me that the RASH document now actually reads like an "how to do HTML properly" guide (as opposed to "how to do HTML differently"). So, given that RASH now uses proper HTML elements for these things, how far away are we now from "RASH = simply write proper HTML"? (…with of course the added conventions like bibliographies.) Best, Ruben
Re: non-blocking sparql engines
Dear Jürgen, > are there any known implementations of sparql engines that are > non-blocking and capable of handling streams? The Linked Data Fragments client (https://github.com/LinkedDataFragments/Client.js) uses asynchronous iterators and is entirely stream-based. Best, Ruben
Re: Recommendation for transformation of RDF/XML to JSON-LD in a web browser?
Hi Frans, > What would be the best or easiest way to do this? Seems that RDF-Ext (https://github.com/rdf-ext/rdf-ext) is the way to go! It supports read/write for both RDX/XML and JSON-LD. Best, Ruben PS You might like the public-rd...@w3.org mailinglist, where we discuss RDF and JavaScript.
Re: Please publish Turtle or JSON-LD instead of RDF/XML [was Re: Recommendation for transformation of RDF/XML to JSON-LD in a web browser?]
> I encourage all RDF publishers to use one of the other standard RDF formats > such as Turtle or JSON-LD. +1 To be honest, even after several years in the SemWeb community, I have to admit I still cannot read RDF/XML. It's just too complicated for me and I don't see a point in learning it, given that Turtle is more compact and easier to read. This is also why I've also vowed to never support RDF/XML in any libraries I write. I'm happy to see that W3C has made Turtle the default for popular documents such as http://www.w3.org/1999/02/22-rdf-syntax-ns. And content negotiation still allows backward-compatibility in any case. Here's an Accept header I typically use for clients: Accept: application/trig;q=1.0,application/n-quads;q=0.7,text/turtle;q=0.6,application/n-triples;q=0.3,text/n3;q=0.2 I first try quad-based formats, then triple-based formats, preferring the abbreviated syntaxes in both cases. It should be noted, however, that gzipping N-Quads/N-Triples can perform better than the added parsing complexity of TriG/Turtle. Best, Ruben
Re: Discovering a query endpoint associated with a given Linked Data resource
Hi Nandana, all, I wonder if it is possible to have a hybrid approach in which the dereferenceable Linked Data resources that optionally advertise query endpoint(s) in a standard way so that the clients can perform queries on related data. For me, the answer is always self-descriptiveness. I thus agree with Hugh's premise: it should be in the document. If you want to tell a client it can do a certain thing, just tell the client it can do a certain thing. For instance, if we want to say you can find data about http://dbpedia.org/resource/Nikola_Tesla in the collection http://fragments.dbpedia.org/2015/en, which you can query as Triple Pattern Fragments, we should just convert this sentence to RDF and add it to representations of http://dbpedia.org/resource/Nikola_Tesla: http://fragments.dbpedia.org/2015/en#dataset hydra:member http://dbpedia.org/page/Nikola_Tesla; hydra:search [ hydra:mapping [ hydra:variable subject; hydra:property rdf:subject ], hydra:mapping [ hydra:variable predicate; hydra:property rdf:predicate ], hydra:mapping [ hydra:variable object; hydra:property rdf:object ], ]. In that case, the only thing we need to standardize on is the hypermedia vocabulary. I believe in such in-band, RDF-based being explicit to clients approaches much more than specific conventions standardized in human-readable specification document. If you think about it, being explicit is also how we do it on the human Web. How would you tell a human it can query your website in a certain way? Well, you would just say that—and provide the controls to do so :-) Best, Ruben
[CfP] Participate in the ESWC2015 Developers Workshop
Dear SemWeb developer, Working on something with Linked Data or SemWeb technology? This is your chance to show it to the world! There are 6 ways in which you can participate in the official ESWC2015 Developers Workshop: 1. You can submit a 4–6 page development paper to tell us about SemWeb software you've written. 2. You can submit a short 1–2 page abstract about your development work. 3. Do you have a cool demo? Show it to us! 4. Your GitHub or other repositories with SemWeb code are totally welcome. We're curious to see them. 5. Start a discussion: write a few lines about a topic of choice. 6. Do you have something else you'd like to show? Just send it in! Contribute to the SemDev community and submit at http://eswc2015.semdev.org/participate/ before 6 March 2015. The workshop is in Portoroz, Slovenia on 31 May or 1 June 2015. Find out more at http://eswc2015.semdev.org/. …and don't hesitate to contact us with your ideas! Best, Ruben and Miel ESWC 2015 Developers Workshop chairs PS Get inspired by some of last edition's contributions: http://iswc2014.semdev.org/program/ or by the Semantic Web Developer of the Year 2014: http://iswc2014.semdev.org/award/
Re: Organisation Linked Data dataset
Hi Bianca, In addition to Paul's answer: There is a full text search facility, a OpenRefine compliant reconciliation API, a sparql endpoint and a linked data fragment server all accessible (with examples) from the home page at http://kbodata.be/. You can easily fire SPARQL queries at the KBO fragments server through our online client: http://client.linkeddatafragments.org/#startFragment=http%3A%2F%2Fdata.kbodata.be%2Ffragments Some examples are included; this might help you discover what's in there. Best, Ruben
Re: Debates of the European Parliament as LOD
Dear Laura, As you said (in your other email) it would be good to add some info on where this data came from. At the moment people don’t know what this dataset is about when they access it on http://data.linkeddatafragments.org, and also we would not mind to be acknowledged ;) Rest assured that more metadata will be coming; we just have to add this functionality to the server implementation. It's on the planned feature list :-) Best, Ruben
Re: Debates of the European Parliament as LOD
Dear Laura, all, Thanks for publishing this dataset under an open license, this is a great example of the power of Linked Data! We have made the dataset available as triple pattern fragments under the following URL: http://data.linkeddatafragments.org/linkedpolitics. This data can now be queried with a Linked Data Fragments client (https://github.com/LinkedDataFragments/Client.js). If people are interested, we can add some example queries to the online client (http://client.linkeddatafragments.org/). Best regards, Ruben
DBpedia now available as triple pattern fragments
Dear DBpedia enthusiasts, DBpedia is perhaps the most widely known Linked Data source on the Web. You can use DBpedia in a variety of ways: by querying the SPARQL endpoint, by browsing Linked Data documents, or by downloading one of the data dumps. Access to all of these data sources is offered free of charge. Last week, a fourth way of accessing DBpedia became publicly available: DBpedia's triple pattern fragments at http://fragments.dbpedia.org/. This interface offers a different balance of trade-offs: it maximizes the availability of DBpedia by offering a simple server and thus moving SPARQL query execution to the client side. Queries will execute slower than on the public SPARQL endpoint, but their execution should be possible close to 100% of the time. Here are some fun things to try: - browse the new interface: http://fragments.dbpedia.org/2014/en?object=dbpedia%3ALinked_Data - make your browser execute a SPARQL query: http://fragments.dbpedia.org/ - add live queries to your application: https://github.com/LinkedDataFragments/Client.js#using-the-library Learn all about triple pattern fragments at the Linked Data Fragments website http://linkeddatafragments.org/, the ISWC2014 paperhttp://linkeddatafragments.org/publications/iswc2014.pdf, and ISWC2014 slides: http://www.slideshare.net/RubenVerborgh/querying-datasets-on-the-web-with-high-availability. We wish you a nice time with this new DBpedia interface! Best regards, Ruben
Re: URIs within URIs
Hi Mark, Indeed. Interestingly, this use case was the first one I published as an example of RDF Forms; http://www.markbaker.ca/2003/10/UriProxy/ It's then probably not a coincidence that the first iteration of triple pattern fragments worked with the RDF Forms vocabulary :-) https://github.com/LinkedDataFragments/Server.js/commit/fe46993ee We switched to the Hydra Core Vocabulary at a later stage. Best, Ruben
Re: URIs within URIs
Hi Luca, I'm wondering however if *form URIs* could themselves be resources rather than datasets. Sure, why not. They're just URIs. For example imagine the example from earlier: http://bar.com/?subject=http%3A%2F%2Ffoo.com%2Falice a void:Dataset . http://foo.com/alice #some #data . Instead of being a void:Dataset, the form URI could simply be a new URI someone defines with an owl:sameAs relation (or other outbound relationships) to the alice URI, such as: http://bar.com/?uri=http%3A%2F%2Ffoo.com%2Falice owl:sameAs http://foo.com/alice; #some #data . We have to be careful with use/mentions though. Is bar.com… really Alice, or a document about Alice? And is foo.com/alice a document, or Alice? Only if both are Alice, the sameAs makes sense. If both are documents, they're probably not the same; if either is a person, then they're certainly not the same. [Note to readers: please don't restart httpRange-14 here.] I guess the differentiation between the two is a simple semantic formality. Can I link to triple pattern fragments datasets as if they were resources? Such as: http://other.com/alice rdfs:seeAlso http://bar.com/?subject=http%3A%2F%2Ffoo.com%2Falice . ? Absolutely. Note that similar constructs are already present in fragment representations: http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FRuben%2BVerborgh contains http://data.mmlab.be/people/Ruben+Verborgh rdfs:seeAlso http://data.mmlab.be/mmlab?object=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FRuben%2BVerborgh. (And note the difference between the person and the document.) Best, Ruben
Re: URIs within URIs
bnodes are Semantic Web, but not Linked Data. If a node doesn't have a universal identifier, it cannot be addressed. I find this comment strange. If you mean that I can’t query using a bnode, then sure. If you mean that I never get any bnodes back as a result of a Linked Data URI GET, then I think not. Yes, you can get back bnodes. But the identifier of a bnode has only meaning in the document it is contained in. Hence, you cannot ask the server anything else about this bnode, because you don't have an identifier for it that exists outside of that one document. Therefore, it's maybe better to not get back bnodes at all; except if the server is sure the client cannot ask further meaningful questions about them (for instance, when all triples about a bnode were already in the response, as is the case with lists, and some other situations as well). Best, Ruben
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.
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 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.
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
Re: Updated LOD Cloud Diagram - Please enter your linked datasets into the datahub.io catalog for inclusion.
Dear Chris, Max Schmachtenberg, Heiko Paulheim and I have crawled of the Web of Linked Data and have drawn an updated LOD Cloud diagram based on the results of the crawl. That's awesome, thanks a lot! Would there be an SVG version at some point? I heard that at some point, people were working on a continuously updating version. I.e., a constraint solver that would generate it more or less automatically, so that new versions would be less of a pain in the future. Would that still be the case? What's the burden of releasing a next version? Best, Ruben
Re: Real-world concept URIs
When do people need to refer to the document or the representation of the animal zebra? If we want to differentiate between I like the zebra; I don't like the document about the zebra. Or more real-world examples: a document about Barack Obama has a different creation date than Barack Obama himself. Best, Ruben
Re: Real-world concept URIs
But why do they need to be on the same domain? They don't need to be. Several parties on different domains can represent information about the animal zebra. They just seem like different things to me. They are, indeed.
[CfP] 6 ways for SemWeb developers to participate
Dear SemWeb developer, This is your chance to show your work to the world! There are 6 ways in which you can participate in the official ISWC2014 Developers Workshop: 1. You can submit a 4–6 page development paper to tell us about SemWeb software you've written. 2. You can submit a short 1–2 page abstract about your development work. 3. Do you have a cool demo? Show it to us! 4. Your GitHub or other repositories with SemWeb code are totally welcome. We're curious to see them. 5. Start a discussion: write a few lines about a topic of choice. 6. Do you have something else you'd like to show? Just send it in! Contribute to the SemDev community and submit at http://iswc2014.semdev.org/submit/ before 20 July 2014. The workshop is in Trentino, Italy on 19/20 October 2014. Find out more at http://iswc2014.semdev.org/participate/. …and don't hesitate to contact me with your ideas! Best, Ruben ISWC 2014 Developers Workshop chair
[CfP] Linked Data developers, ISWC2014 wants you!
Dear Linked Data developers, You've been working on a great Linked Data project, and now you want to put it in the spotlights? Rightfully so! For the first time, this ISWC2014 Developers Workshop offers you the opportunity to talk about those things that matter to all of us: - How to develop applications on top of Linked Data? - How can browser applications influence the Semantic Web? - How to create libraries for RDF (JSON-LD / Turtle / …), SPARQL, PROV? - What about mobile and native applications? - How to do semantic development for a specific domain? In other words, this workshop is about how you made things work. It is about implementations, methods, techniques, about how you solved practical problems for Linked Data. The central theme for the first edition is the Semantic Web in the browser, but all developer contributions are welcome. Concretely, we were thinking about the following topics: - Web applications - Web APIs - browser extensions - libraries (client-side or server-side) - visualizations - user interfaces - end-user tools - development tools - data or ontology processors - application development (processors, reasoners, …) - … Participate by submitting a development paper of 4 to 6 pages (LNCS) that describes how your implementation tackles a specific need. Focus on lessons learnt, mention how people can use your software. Submission deadline: 20 July 2014 Notification: 1 September 2014 Presentation: 19 or 20 October 2014 Submission: https://www.easychair.org/conferences/?conf=iswc2014dev Learn more at http://iswc2014.semdev.org/ and follow @SemWebDev. See you at ISWC2014! Ruben Verborgh SemWeb developer
Re: How to avoid that collections break relationships
Hi Peter, Ok, I describe ex:BaseballPlayer as ex:BaseballPlayer owl:equivalentClass _:x . _:x owl:intersectionOf ( ex:Person [ owl:onProperty ex:plays; owl:hasValue ex:Baseball ] ) Is this RDF? Yes. Should all consumers of RDF understand all of this? Yes, depending on your interpretation of understand. All of them should parse the triples. This is where RDF ends. Those that can interpret OWL will be able to infer additional things. This is OWL and not part of the RDF model (and thus also not extending the RDF model). h1Baseball player/h1 doesn't extend HTML. It just applies HTML to describe a baseball player. No, quantification is not part of RDF. Why not? It is not in the spec. I could certainly define an encoding of quanfification in RDF and use it to define predicates. You indeed can. Predicates may not influence non-related triples, however, other triples might be influenced through a cascade of relations. Why not? I can define predicates however I want, after all? Because, by definition of related, if your predicate is defined to influence a certain (kind of) triple, that triple is related to the usage of the predicate. What does using owl:differentFrom in RDF commit you to? It says that two things are different. Clients that can interpret this predicate can apply its meaning. This application does not change the model. What model? The RDF model. Do you mean that all you care about is the abstract syntax? No. What about rdf:type? What about rdfs:domain? Do all consumers of RDF need to commit to the standard meaning of these predicates? Yes. RDF is just the model. Giving a predicate meaning is not extending the model. How so? What else is giving a predicate meaning besides extending the model? It defines something on top of the model. Building a home with bricks does not extend the bricks; it uses them. I am really struggling to understand your view of RDF. Likewise. But maybe further discussing this doesn't really help the community. My view on RDF works for what I want to do and in my opinion, it's by no means an unreasonable view. But there might be other views… and that might just be fine. Best, Ruben
Re: Linked Data Fragments: Web-scale querying
Hi Kingsley, How about making an RDF document that describes LDF? Producing such a document would make its value proposition clearer. This approach is also a nice case of Linked Data dog-fooding e.g., the basis for the most basic LDF utility example using an RDF document as the data source :-) It took me some time because of the WWW conference, but here it is: http://linkeddatafragments.org/description/ URIBurn at will ;-) Best, Ruben
Re: How to avoid that collections break relationships
What then is RDF for you? The Resource Description Framework. It is a framework to describe resources, and this includes predicates. Anybody can define predicates the way they want, otherwise RDF is useless to express semantics. For example, do you consider N3 to be RDF? No, quantification is not part of RDF. Can predicates have non-local effects? A predicate indicates a relationship between an object and a subject. What this relationship means is described in the ontology to which the predicate belongs. Predicates may not influence non-related triples, however, other triples might be influenced through a cascade of relations. What does using owl:differentFrom in RDF commit you to? It says that two things are different. Clients that can interpret this predicate can apply its meaning. This application does not change the model. To me, what RDF does not do is just as important and what it does do. This means that RDF captures only the RDF bit of the meaning of predicates - the rest of their meaning remains inaccessible from RDF. Any attempt to go beyond this is … going beyond RDF and it is very important do realize this. RDF is just the model. Giving a predicate meaning is not extending the model. Best, Ruben
Re: How to avoid that collections break relationships
Dear all, Sorry for hacking the discussion, but I think we should keep the discussion goal-focused. So let's therefore see what we want to achieve: 1. Having a way for clients to find out the members of a specific collection 2. Not breaking the RDF model while doing so A solution that satisfies 1 and 2 with minimal effort is good enough for Hydra; the rest can be discussed more deeply in other places. The easiest solution I could come up with that satisfies the above criteria is the following. Suppose a client needs to find Markus' friends, and the server use foaf:knows for that (which has the restrictive range foaf:Person, disallowing a collection). If the representation contains all of Markus' friends, then it could look like: /people/markus foaf:knows /people/Anna. /people/markus foaf:knows /people/Bert. /people/markus foaf:knows /people/Carl. Now, more interestingly, if the list of Markus' friends is available as a separate resource /people/markus/friends, then it could look like: /people/markus foaf:knows [ hydra:memberOf /people/markus/friends ]. So we say that a blank node is one of Markus' friends, and where it can be found. This satisfies 1, because the client can follow the link and find all friends there. This satisfies 2, because the blank node is an actual person, not a collection. And that is all we need for hypermedia clients to work. Yes, I know this does not add a whole bunch of extensive semantics we might need for specific case X, but: a) that's not necessary in general; a Hydra client has all it needs; b) this solution is extensible to allow for that. If you like, you can add details about /people/markus/friends, say that they all have a foaf:knows relationship to /people/markus etc. Summarized: look at the minimum client needs, implement that; only thing we need is a blank node and a memberOf predicate. Hydra clients work; the model is happy too. Best, Ruben PS The only case this slightly breaks the model is if Markus has no friends yet; then you say Markus knows somebody while he actually doesn't. But saying something doesn't exists is a problem in RDF anyway. The easy way: just don't include any foaf:knows triple (or ignore slight breakage). If you insist to include _something_, we'd need to do have an explicit empty list: /people/markus foaf:knowsList (). foaf:knowsList hydra:listPropertyOf foaf:knows. But then we'd be stuck with twice as many properties, which is not ideal either.
Re: How to avoid that collections break relationships
Hi Peter, This is why I started by saying the focus of the discussion should be on what we want to achieve. With my proposed solution, it is achieved. Furthermore, this solution allows you to add any metadata you might like; a Hydra client just wouldn't need it (even though others might). Right now, don't need anything else than just finding the members of a collection. But this is violating both the spirit and the letter of RDF. It would be better to introduce entirely new syntactic mechanisms A new syntax would break everything that exists. How is that better? The proposed approach doesn't break anything and achieves what we need, without violating the RDF model. Huh? If you want to be in the RDF camp, you have to play by RDF rules. And we do that. /people/markus foaf:knows [ hydra:memberOf /people/markus/friends ]. means “Markus knows somebody who is a member of collection X. Check that collection X to find out if Markus knows more of them. I'm not saying there will be more in there… just saying that you could check it. Handy for a hypermedia client. Works in practice, doesn't break the model. If you want more semantics, just add them: /people/markus/friends :isACollectionOf [ :hasPredicate foaf:knows; :hasSubject /people/Markus ] But that is _not_ needed to achieve my 1 and 2. Best, Ruben
Re: How to avoid that collections break relationships
/people/markus foaf:knows [ hydra:memberOf /people/markus/friends ]. means “Markus knows somebody who is a member of collection X. But that's not what this says. It says that Markus knows some entity that is related by an unknown relationship to some unknown other entity. Well, obviously we'd have to define the hydra:memberOf predicate… It's not helpful to interpret foaf:knows as knows but hydra:memberOf as unknown relationship”. And “unknown entity” is intended; this is why you have to fetch it if you're curious. If you want more semantics, just add them: /people/markus/friends :isACollectionOf [ :hasPredicate foaf:knows; :hasSubject /people/Markus ] But that is _not_ needed to achieve my 1 and 2. Well this certainly adds more triples. Whether it adds more meaning is a separate issue. Obviously, we'd define isACollectionOf as well. It appears that you feel that adding significant new expressive power is somehow less of a change than adding new syntax. I'm not adding any new expressive power. Can you point exactly to where you think I'm doing that? Yes, I define a memberOf predicate that clients have to understand. But that's a given if we just define it was owl:inverseProperty hydra:member. Best, Ruben
Re: How to avoid that collections break relationships
Peter, Please, let's get the discussion back to what we want to achieve in the first place. Right now, the solution is being evaluated on a dozen of other things that are not relevant. Proposal: let's discuss the whole abstract RDF container thing on public-lod@w3.org, and solutions to make clients work at public-hy...@w3.org. We're talking here about making clients able to get the members of something. Yes, they will need to interpret some properties. Just like an OWL reasoner needs to interpret owl:sameAs, a Hydra client needs to interpret hydra:member. That is how applications work. In no way, defining a vocabulary is extending RDF. RDF is a framework. I'm not adding to the framework. I'm proposing a simple property hydra:memberOf owl:inverseProperty hydra:member. If you really don't like me introducing a property, here's an alternative way of saying the same thing: /people/markus foaf:knows _:x. /people/markus/friends hydra:member _:x. There you go. hydra:member was already defined, I'm not inventing or adding anything. You want to depend on a particular reading of this non-RDF predicate, and have this reading trigger inferences. No I don't want any of that. Why do think I'd want that? Where did I say I want inferences? Where do I need them? Also, how could it possibly be a non-RDF predicate? RDF simply defines a predicate as an IRI [1]. Again making a significant addition to RDF. When did defining a vocabulary become adding to RDF? Which is precisely my point. You are using OWL, not just RDF. If you want to do this in a way that fits in better with RDF, it would be better to add to the syntax of RDF without adding to the semantics of RDF. …but this has _never_ been about extending RDF in any way, nor has it been about only using RDF or only using OWL. We don't want any of that. We want: 1. Having a way for clients to find out the members of a specific collection 2. Not breaking the RDF model while doing so The proposed solution achieves both objectives. Best, Ruben [1] http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-predicate
Re: How to avoid that collections break relationships
In actuality, defining things like owl:sameAs is indeed extending RDF. Defining things in terms of OWL connectives also goes beyond RDF. This is different from introducing domain predicates like foaf:friends. (Yes, it is sometimes a bit hard to figure out which side of the line one is on.) Thanks for clarifying, and this is indeed where we disagree. For me, such a line does not exist, nor was it ever defined. And even if there were, I don't see the need to draw it. RDF is the framework, the interpretation is semantics. All predicates have meaning associated with them, none has “more” meaning than the other; maybe some usually allow to infer more triples, but that doesn't change the framework at all. Cheers, Ruben
Re: How to avoid that collections break relationships
Hi Markus,
Check that collection X to find out if Markus knows more of them.
That second sentence is where this approach loses its appeal for me. IMO, it
doesn't really suggest to go and check collection X to find out if Markus
knows more of them. Of course, you can always do, but why should you.
Fully agree of course; but we could look at it the other way:
the server decides what is a good idea to include.
In most cases, it doesn't really make sense to add
/people/markus/friends foaf:knows [ hydra:memberOf /soccerteams/spain ].
Okay, Markus knows a Spanish soccer player… Why put it like that?
I realize this is limited as-is, but good for many cases.
And for the other cases, detailing /soccerteams/spain is the way to go.
{
@id: /markus,
hasRelationshipIndirection: {
property: schema:knows,
resource: /markus/friends
}
}
I like the concept, maybe not this exact execution.
Concretely, “hasRelationshipIndirection is quite impossible to intuitively
grasp.
Something along the lines of
{
@id: /markus,
hasList: {
property: schema:knows,
object: /markus/friends
}
}
seems easier to me. (hasList, hasMany, relatesTo, relatesToMany, …)
It could also be tweaked into something like
{
@id: /markus,
hasRelationshipIndirector: {
schema:knows: /markus/friends
}
}
so that it works nicely with property paths.
But then (and this is where I would agree with Peter)
you're really going beyond RDF model semantics;
there is some string interpretation required.
I don't like that, even though it is more general.
Best,
Ruben
Re: Linked Data Fragments: Web-scale querying
somewhat related to this direction there is a good project I'd like to see integrated on sparql endpoints and linked data api in general: https://helloreverb.com/developers/swagger The difference between Swagger and Hydra is that Swagger proposes a contract in advance. That would be like reading a document to use Google, type /?q=search+term” but that's not how the Web works. Instead, Hydra provides hypermedia controls that allow autonomous clients to find their way without inspecting any documentation beforehand: http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/api-demo/ Best, Ruben
Re: Linked Data Fragments: Web-scale querying
Hi Luca,
1. Are the parameters standard? Do they have to be called
`?predicate=subject=object=`?
Good question, I'm glad you asked because the answer is no :-)
LDF clients should be entirely hypermedia-driven,
so they should not make any assumptions about URI structure.
Instead, controls to access fragments are sent by the server,
which is then free to choose its own URI space.
The controls are entirely self-descriptive using RDF and Hydra.
Concretely, the Turtle representation of
http://data.linkeddatafragments.org/dbpedia?object=dbpedia%3AYork
has something like this:
http://data.linkeddatafragments.org/dbpedia a void:Dataset,
hydra:Collection;
void:subset
http://data.linkeddatafragments.org/dbpedia?object=dbpedia%3AYork;
void:uriLookupEndpoint
http://data.linkeddatafragments.org/dbpedia{?subject,predicate,object};;
hydra:search _:triplePattern.
_:triplePattern hydra:template
http://data.linkeddatafragments.org/dbpedia{?subject,predicate,object};;
hydra:mapping _:subject, _:predicate, _:object.
_:subject hydra:variable subject;
hydra:property rdf:subject.
_:predicate hydra:variable predicate;
hydra:property rdf:predicate.
_:object hydra:variable object;
hydra:property rdf:object.
So using the Hydra vocabulary, you can specify
that your server uses a different template. For instance, {?s,p,o}:
:dbpedia a void:Dataset, hydra:Collection;
void:subset http://example.org/dbpedia?o=dbpedia%3AYork;
void:uriLookupEndpoint http://example.org/dbpedia{?s,p,o};;
hydra:search _:triplePattern.
_:triplePattern hydra:template
http://data.linkeddatafragments.org/dbpedia{?subject,predicate,object};;
hydra:mapping _:subject, _:predicate, _:object.
_:subject hydra:variable s;
hydra:property rdf:subject.
_:predicate hydra:variable p;
hydra:property rdf:predicate.
_:object hydra:variable o;
hydra:property rdf:object.
Note how we express that rdf:predicate corresponds to the ?p parameter.
2. Is there a page somewhere that describes these parameters? For
example, how do I limit a specific set? Is there a `?limit=10`
parameter in the standard? And how would I do pagination? Ex: is there
`?offset=`?
So yes, any fragment describes those parameters ;-)
There are no limits or offsets.
The server is free to choose its own page length.
Paging is not yet implemented in the currently available code,
but this will be available through hypermedia controls as well.
There would simply be a link to the next page, likely hydra:nextPage.
3. In the paper it says This would involve support for filters; one
way to implement them is to o ffer ldfs with regular expression
selectors. Such features would then also be indicated by a server..
Again, is there a standard way of doing this and does basic LDF
enforce these rules are are they left to the server implementation?
Everything would be self-descriptive again;
server responses indicate how you can filter with regular expressions.
See the thread on the Hydra mailing list:
http://lists.w3.org/Archives/Public/public-hydra/2014Mar/0051.html
We will eventually look for ways to standardize some of these things.
For instance, we want to standardize what a basic Linked Data Fragment is,
using what kind of vocabulary its controls should be described.
However, there will never be hard-coded client/server contracts in terms of
URIs.
The interaction should be driven by hypermedia;
that way, fragments can be retrieved in a server-agnostic way
(even across different servers).
What I like about this is that it offers extra special parameters such
as `?_page=` but also filters like:
http://keithalexander.co.uk/ecco-tcp/?dct:date;_max=1795 using some
special path-based language that I'm not quite familiar with.
That could indeed be another way of offering fragments;
however, this would be harder to capture with HTML forms
and harder to describe with URI templates.
For now I'm not that interested in filters as complex as SPARQL
FILTERs, but more interested in providing at least pagination so was
wondering how basic LDF servers do that.
So it will be hypermedia-driven.
I will soon add this to the public codebase.
i'll keep you updated;
please do keep us updated of your progress too :-)
Best,
Ruben
Re: Linked Data Fragments: Web-scale querying
Hi Luca, Wouldn't it be better to *not* have the metadata return at each call or is it necessary in order to make hypermedia clients work? But then only specific basic Linked Data Fragment clients would be able to access the API. This is exactly what I want to avoid, for two reasons: 1) I envision different kinds of clients using APIs, and that is only possible if those APIs are self-descriptive. 2) I envision different kinds of APIs emerging. What you've seen now is only the beginning of LDF; basic Linked Data Fragments are only one kind of fragments. Dozens of other possible fragments can be imagined, including SPARQL endpoints and subject pages existing today. For me, those two points are the reason why the Linked Data Platform is way too narrow. It only defines one kind of API; take it or leave it. Clients have to be coded specifically for this API; the API cannot evolve without a new specification. In contrast, to _query_ basic Linked Data Fragments, clients only have to understand the hypermedia controls. Moreover, if they just need to _browse_ those fragments, they don't have to understand anything, as they can just follow links. On that line, if I simply returned the data, without metadata, would that still be a valid LDF? A valid Linked Data Fragment, but not a valid basic Linked Data Fragment. According to the definition [1]: A basic Linked Data Fragment (basic LDF) is a Linked Data Fragment with a triple pattern as selector, count metadata, and the controls to retrieve any other basic LDF of the same dataset, in particular other fragments the matching elements belong to. Note how we implemented this last constraint (in particular…) by adding direct links to fragments with overlapping components, in addition to the Hydra hypermedia controls that allow to retrieve _any_ fragment. Best, Ruben [1] http://linkeddatafragments.org/publications/ldow2014.pdf
Re: Linked Data Fragments: Web-scale querying
Hi Luca, Wouldn't it be better to *not* have the metadata return at each call or is it necessary in order to make hypermedia clients work? Put differently, one could say: “Why don't we just remove the search box from all Google and Yahoo pages? Everybody knows you just need to type in /?q=search+term.” It's about more than just convenience, really. Fielding defines hypermedia as: [t]he simultaneous presentation of information and controls such that the information becomes the affordance through which the user (or automaton) obtains choices and selects actions.” [1] And if we want machines using the Web in an autonomous way, we have to provide them with similar affordance as humans [2]. Best, Ruben [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven [2] http://ruben.verborgh.org/phd/conclusion/
Re: Linked Data Fragments: Web-scale querying
Hi Luca, But imho as a community we have to strike a balance between how much boilerplate we can put on developers hands and how much automation we can achieve with that. We can use libraries to avoid boilerplate. An HTML form is the standard way to represent hypermedia controls in HTML. Parsing an HTML form is straightforward; if Hydra becomes the (de-facto) standard way to represent hypermedia controls in RDF, then parsing it will also be straightforward. Right now, the snippet I posted is probably perceived as a collection of triples; they can be hard to grasp. However, once libraries allow such snippets to be viewed as just hypermedia controls (which they represent); it will be as easy as an HTML form. So in a way, the extra automation comes with a cost because you're asking data-providers to provide extra information that would otherwise be somewhat useless if you're not an automated hypermedia client. That's correct and I'm asking that on purpose. The alternative is that those data providers can only be used by clients that are hard-coded for that task. Far less attractive. Linked Data Fragments are about building servers in a way that enables intelligent clients. The Turtle representation of basic LDFs have been purposely designed to have automated hypermedia clients as consumers. Everybody is free to build servers that serve other representations; however, one cannot expect autonomous clients to use those servers if controls are not provided. That's why Basic LDFs do provide those. I think that the fact that basic LDF supports metadata is extremely important, but perhaps there can be a way to define some implicit metadata in the basic LDF standard? If such implicit rules should exist, API access would be limited to only those few clients that have these rules hard-coded. In contrast, any client that can parse hypermedia controls can access basic Linked Data Fragments. Otherwise I can just call my service an LDF (very close to basic LDF) and forget about the formalities, but it probably won't work with a basic LDF client right? It wouldn't. And it wouldn't work with a hypermedia client either. Your service would need a specifically written client to work, and that's exactly what I want to avoid. I'm just wondering if there's a way that we can be less formal but still achieve a good balance between automation and usability. It's not formal; that's just the RDF way to describe hypermedia controls. Put a library on top of that and you can access those controls transparently. Alternatively, you can retrieve the HTML representation and use the form. In short: I'm not providing a hard-coded URL contract but instead a self-descriptive hypermedia mechanism in order to serve more clients than just hard-coded ones. Best, Ruben
Re: Linked Data Fragments: Web-scale querying
Hi Luca, Just finished reading the paper. Really great stuff. The idea of splitting a single resourceful SPARQL request into multiple fine-grained requests was always attractive to me and I've also thought of something similar (http://lmatteis.github.io/restpark/). I applaud you and your team for coming up with a formal client algorithm as well as a server implementation for offering this functionality. Thanks and some of the ideas seem similar to Restpark, especially the URI template and the examples, which come down to concrete applications of our algorithm. The main difference in the design process, I think, is that I started looking at it from the client perspective: what affordance does a client need to solve queries? Incorporating the total triple count and links to other fragments are very important to allow the right client-side decisions. I wonder, given a Linked Data set, if you could easily and generically wrap it with a basic LDF interface. Sort of how Pubby wraps SPARQL to expose Linked Data, maybe there can be a wrapper for a Linked Data site to expose basic LDF. In addition to Pieter's answer, who correctly points at the implementation of third-party tools, I would also point to our open-source basic LDF server: https://github.com/LinkedDataFragments/Server#supported-data-sources As you can see, it supports many back-ends out-of-the-box. This includes SPARQL endpoints, but also other triple sources such as Turtle files, and even other basic LDF sources. An interesting back-end is HDT (http://www.rdfhdt.org/), which we use to offer http://data.linkeddatafragments.org/dbpedia. * I build a nice site and my data is available as HTML, marked up with RDFa * Database is not a triple store, just regular MySQL So the easiest way to publish this as fragments could be to extend Datasource. For an example on how to do this, see https://github.com/LinkedDataFragments/Server/blob/master/lib/LevelGraphDatasource.js. Where I see LDF being a *huge* deal is that I could use something to wrap my RDFa pages and expose a basic LDF server, without having to change any of my technology stack for my app. This could potentially allow thousands of RDFa providers to expose querying functionality with minimum effort. Indeed, and that's exactly what we aim for with basic LDFs: low-cost, queryable publishing of Linked Data. Let us know how it works out, or if we can help! Best, Ruben
Re: representing hypermedia controls in RDF
Hi Gannon, [Sorry for the delay, your mail accidentally skipped my inbox!] My question can be rephrased thus: Does the theoretical size of the target audience for a distributed affordance matter ? The audience size doesn't matter, as each user has personal preferences. The idea is that the client has an extra piece of intelligence that adds the actions the user cares about. For instance, if you prefer to see movies in a certain theatre and always buy books through Barnes Noble, then you will bookmark those actions. When your client (browser) then arrives on a page with a movie or book, it will automatically insert links to buy tickets for that theatre or order through Barnes Noble, instead of suggesting Netflix, Amazon or iTunes. As the processing happens on the client side, we can scale without impacting the infrastructure. It seems to me that distributed entails that one size fits does not fit all clients, that constrains the Open World … Exactly! But this is why the client performs the adaptation: it's personalized and scalable in the number of clients. Is this the answer you're looking for? Additionally, the diagram in http://ruben.verborgh.org/publications/verborgh_wsrest_2013/ might clarify things. Best, Ruben
Re: representing hypermedia controls in RDF
Hi Kingsley, Are words such as enables , facilitates etc.. so bad that we can no longer make statements like: a/ enables name to address indirection in HTML via URIs? Basically, that it enables exploitation URI serve dually as a document name and a content access address i.e., a hyperlink. Would REST be less useful if the word affordance wasn't engrained in its narrative? In my talks, I say that enabling is stronger than affording. You can visit the page without the link, that's enabled by the server. (E.g., you can copy/paste a URI in to the address bar.) However, the link affords it: it has an actionable property that lets you do it directly (even though you could do it without). Best, Ruben
Re: representing hypermedia controls in RDF
Hi Kingsley, In my talks, I say that enabling is stronger than affording. Do you have a link to the talk in question? Well, it's something I always mention verbally, so enabling will not be on the slides. Nevertheless, here's a presentation on it for a wide audience: http://www.slideshare.net/RubenVerborgh/the-web-a-hypermedia-story On slides 41–46, I explain Fielding's definition of hypermedia, with slides 44–46 specifically focusing on affordance. And here are slides for my research project Distributed Affordance (what's in a name), which explains the topic in a similar way on slides 7–18: http://www.slideshare.net/RubenVerborgh/distributed-affordance-21175728 Affordance is in my opinion the crucial word that defines the REST architectural style, as its loose conversational coupling is only possible because representations _afford_ subsequent actions; RPC-style interactions just _enable_ those actions. Best, Ruben
Re: representing hypermedia controls in RDF
Hi Kingsley Note, Affordance doesn't show up in any of the standard dictionaries I have access to. That said, it does have a Wiktionary entry [1], but that particular definition doesn't actually make a case for it being immutable or devoid of an alternative :-) Norman's The Design of Everyday Things describes the word nicely. In case it is of any help, my understanding of the word affordance is based on the verb: - a URL enables addressing a resource = the URL is an enabler; - the link affords going to the resource = the link is an affordance. Best, Ruben
Re: representing hypermedia controls in RDF
Hi Gannon, Are you thinking in terms of IPv4 or IPv6 ? I'm sorry but I lost you here… how can I IPv4/6 relate to this? Best, Ruben
Re: representing hypermedia controls in RDF
Hi Markus,
You probably already expected me asking this :-) Why not Hydra [1]?
Ah, there you are! Welcome ;-)
- representing hyperlinks in RDF (in addition to subject/object URLs)
hydra:Resource along with hydra:Link covers that: http://bit.ly/1b9IK32
And it does it the way I like: resource-oriented!
Yet, the semantic gap I need to bridge is on the level of predicates.
None of the Hydra properties [1] have hydra:Link as range or domain.
So how to connect a link to a resource?
More or less like:
a
href=http://en.wikipedia.org/wiki/Daft_Punk;http://dbpedia.org/resource/Daft_Punk/a
On the human Web, we do this all the time:
a href=http://en.wikipedia.org/wiki/Daft_Punk;Daft Punk/a
The difference of course with the Semantic Web is that the identifiers need to
be URIs, not labels.
I guess a seeAlso would do, (but then again, seeAlso probably applies to
anything):
dbpedia:Daft_Punk rdfs:seeAlso wikipedia:Daft_Punk.
However, I really want something stronger here.
But perhaps usual hyperlinks are not interesting enough,
as they can actually be represented as predicates (= typed links):
dbpedia:Daft_Punk :hasArticle wikipedia:Daft_Punk.
- representing URI templates [2]
It's covered by hydra:IriTemplate: http://bit.ly/1e2z2NW
Now this case is much more interesting than simple links :-)
Same semantic problem for me though:
what predicates do I use to connect them to my resource?
For instance:
/users :membersHaveTemplate :UsersTemplate.
:UsersTemplate a hydra:IriTemplate;
hydra:template /users/{userid}.
So what I actually need is the equivalent of hydra:members,
but then with a template as range.
Should we discuss take this to the Hydra list? I'd be interested!
(Also, have you considered hydra:template's range as something more specific
than xsd:string?)
- representing forms (in the HTML sense)
In Hydra this is done by a combination of hydra:Operation, hydra:expects and
hydra:supportedProperties, see http://bit.ly/17t9ecB
I like example 10 in that regard, but I'm stuck at predicates again:
how to connect the Link to the resource it applies to?
Btw. for those who don't know, there's a W3C Community Group working on Hydra
[2].
I should be more active there. Perhaps this is a starting point!
Best,
Ruben
Re: representing hypermedia controls in RDF
Server: cloudflare-nginx All fine at my end though so everything should work. Not sure if it's of any help, but CloudFlare doesn't do content negotiation; i.e., as soon as one representation is cached, it always serves that one, regardless of any Accept headers sent by subsequent clients. (And I'd be happy if somebody knew a free cache service that does it right.) Ruben
representing hypermedia controls in RDF
Dear all, Do we have other approaches besides RDF Forms [1] to represent hypermedia controls in RDF? Basically, I’m looking for any of the following: - representing hyperlinks in RDF (in addition to subject/object URLs) - representing URI templates [2] - representing forms (in the HTML sense) I’m aware of CoIN, which describes URI construction [2]. Is it used? Pointers to vocabularies or examples would be very much appreciated! Thanks, Ruben [1] http://www.markbaker.ca/2003/05/RDF-Forms/ [2] http://tools.ietf.org/html/rfc6570 [2] http://court.googlecode.com/hg/resources/docs/coin/spec.html
Re: representing hypermedia controls in RDF
Hi Phil, Thanks for the pointer. POWDER is definitely interesting and relevant, but I’m a bit hesitant to apply regexing. In general, I’m quite a fan of opaque URLs; that is, let the server maintain full control. While HTML GET forms are a level-breaker in that regard, I like the strictness about them: there’s only one way to get from the form to a URL, and the server is still in control because it created the form. What are your thoughts about this? Best, Ruben On 20 Nov 2013, at 11:37, Phil Archer ph...@w3.org wrote: I'm interested in the answers you get to the first and last of your questions but the middle one I can do. The under used POWDER Recommendation allows you to make statements about resources based on URI patterns (with due semantic integrity [1]) - which may or may not be useful to you. See http://www.w3.org/TR/powder-grouping/ HTH Phil. [1] http://www.w3.org/TR/powder-formal/
Re: representing hypermedia controls in RDF
Hi Martynas,
- URI templates: Linked Data API vocabulary
https://code.google.com/p/linked-data-api/wiki/API_Vocabulary
Cool, I do like that. Have you thought about extending to RFC6570?
Do you know about usage of this vocabulary?
The one thing that I like less is the notion of endpoints.
While this is perfect for SPARQL, which is indeed an endpoint
or “data-handling process” that expects a “block of data” [1],
it does not work well in resource-oriented environments.
I’m looking for predicates that work with groups of resource, such as:
/topics/Global_Warming :belongsTo /topics.
/topics a :ResourceList;
api:itemTemplate /topics/{topicID}.
That is, I don't consider there to be a topics endpoint;
instead, there is a topics resource which lists several topics,
and individual topics can be accessed by ID.
The reason I would still need the template is because /topics/ is not
exhaustive,
and new elements can be created by following the template.
This would be equivalent to a HTML GET form.
- HTML forms: RDF/POST encoding http://www.lsrn.org/semweb/rdfpost.html
Interesting, thanks!
Best,
Ruben
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
Re: representing hypermedia controls in RDF
Hi Ed, CC: Mark Baker, I've actually been part of the LDP group; I fully agreed with Mark's concern on the lack of hypermedia controls [1]. LDP is based on a set of agreements, not on a set of dynamic affordances. Would have loved to see a proposal such as this one [2] make it, but it was then clarified that the goal of LDP was to make one API [3]. Best, Ruben [1] http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0007.html [2] http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0018.html [3] http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0029.html On 20 Nov 2013, at 12:49, Edward Summers e...@pobox.com wrote: Hi Ruben, I haven’t used it (or really read the spec) but you might be interested in taking a look at the Linked Data Platform 1,2], which provides some patterns for expressing create/update/delete hypermedia controls in RDF. I’d be interested to hear what your specific use case is. //Ed
Re: representing hypermedia controls in RDF
Hi Norman, Interesting pointer, thanks, I'm amazed to see this existed for so long! HyTime defines a set of hypertext-oriented element types that [let] document authors to build hypertext and multimedia presentations in a standardized way. The issue is probably to integrate this on the RDF level, e.g., those semantics but written as RDF. While I like the conceptual level of abstraction, at some point, you have to serialize it, and this is where I'm at. Best, Ruben
Re: representing hypermedia controls in RDF
Hi Ed, Forgot to answer this part: I’d be interested to hear what your specific use case is. In my research [1], I'm looking at giving machines the same affordances as people. Many things on today's Web cannot be done by machines due to a lack of affordances. While RDF allows to interpret data and facts, it does not help to interpret actions. So use cases I'm looking at are: - how to represent a HTML page with a form in RDF, so automated clients can use it? - how to make such clients search? - how to make them execute state-changing actions? Giving them access to hypermedia controls is a crucial part in that [2]. Best, Ruben [1] http://ruben.verborgh.org/publications/ [2] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Re: Turtle test suite finalized
Hi Gregg, Report updated with your latest results. Note that doap:name was set to node-n3, which is used to display the name of the project; this conflicts with Ruben's node-n3 report; I took the liberty of changing it to EYE, which was used in dc:title. Thanks for pointing that out; has been corrected in the live EARL report: https://raw.github.com/RubenVerborgh/EyeEarl/earl/earl-report.ttl Best regards, Ruben
Re: Turtle test suite finalized
Dear Erik, Congratulations on finalizing the test suite! Please re-submit implementations reports for Turtle so you can 1. Help us push Turtle to final Recommendation status. 2. Raise public awareness of your implementation. Here is the latest version of the EARL report for node-n3, the JavaScript Turtle parser: https://raw.github.com/RubenVerborgh/node-n3/earl/earl-node-n3.ttl The CR comments wiki page has a list of currently submitted implementations, but those will need to be re-run with this final version of the tests. http://www.w3.org/2011/rdf-wg/wiki/Turtle_Candidate_Recommendation_Comments#Implementations Please note that entry 1 is superseded by entry 7 (and thus now by the current submission). Also, the capitalization is “node-n3”, as in 7. Best regards, Ruben
2nd CfP: Services and Applications over Linked APIs and Data (ESWC workshop)
Dear data and API enthusiasts, Do you have a great idea that combines Linked Data and APIs? Then you should consider submitting to the SALAD EWSC2013 workshop. We look forward to your creative work on Linked Data and APIs! Questions? Don’t hesitate to contact us! The workshop takes places on May 26 in Montpelier, France featuring an intriguing keynote “Autonomous Agents on the Web: Beyond Linking and Meaning” by Mike Amundsen. See you in Montpelier! The SALAD2013 team Services and Applications over Linked APIs and Data (ESWC workshop) http://salad2013.linkedservices.org/ SALAD ingredients Who? people from the Semantic Web, Web services, and REST communities What? novel ideas, concepts, and applications that combine Linked Data and Web APIs / services When? ESWC workshop on May 26, 2013 – submission deadline: March 4, 2013 How? an interactive workshop with lots of discussion, accepted paper presentations and keynote speaker Mike Amundsen (http://amundsen.com/blog/) Where? Montpellier, France at the ESWC conference (http://2013.eswc-conferences.org/) ⚖ Recipe Current developments on the Web have been marked by the increased use and popularity of Linked Data and Web APIs. However, these two technologies remain mostly disjunct in terms of developing solutions and applications in an integrated way. Therefore, we aim to explore the possibilities of facilitating a better integration of Web APIs and Linked Data, thus enabling the harvesting and provisioning of data through applications and services on the Web. In particular, we focus on investigating how resources exposed via Web APIs can be used together with Web semantic data, as means for enabling a shared use and providing a basis for developing rich applications on top. ✎ Shopping list The main goal of this workshop is to explore the possibilities of enabling a more integrated and automated use of Web APIs, given the context of the growing importance of Linked Data and applications, benefiting from the available resources. Relevant topics include: - integrated use of Linked Data and Web APIs - moving from individual APIs and data sets towards integrated solutions - differences and parallels between Linked Data and Web APIs - semantically discovering, searching, and browsing Web APIs - describing Web APIs and Linked Data - intelligent clients for Linked Data and APIs - methods for automatically dealing with failures in Web APIs - approaches for the creation of Web API directories The above list is not exhaustive and we therefore actively encourage participants to be creative. A final goal is to provide future initiatives with the devised ideas and visions to stimulate innovation in this research area. ♨ Preparation instructions Would you like to show your work at the SALAD workshop? Great! We offer several opportunities to participate in SALAD: - long papers: up to 8 pages (if you need more, just e-mail us at eswcsalad2...@gmail.com) - short papers: up to 4 pages - demos: up to 2 pages - food for thought: 1 page / slide / web page / image / movie Your submission can be posted through EasyChair (https://www.easychair.org/conferences/?conf=salad2013) or e-mailed (eswcsalad2...@gmail.com). Accepted papers will be published as CEUR workshop proceedings. Selected papers will be included in a separate ESWC workshop papers volume. ⌚ Preparation time Submission: March 4, 2013. Notification: April 1, 2013 Camera ready: April 15, 2013. Workshop: May 26/27, 2013. ⚘ Nutritional information Program committee Sudhir Agarwal, Stanford University, USA Jan Algermissen, NORD Software Consulting José Luis Ambite, University of Southern California, USA Mike Amundsen, Layer 7, USA Sven Casteleyn, Vrije Universiteit Brussel, Belgium Florian Daniel, University of Trento, Italy Peter Haase, fluidOps, Germany Armin Haller, CSIRO, Australia Andreas Harth, Karlsruhe Institute of Technology, Germany Katja Hose, Aalborg University, Denmark Geert-Jan Houben, TU Delft, Netherlands Jacek Kopecký, KMi, Open University, UK Erik Mannens, iMinds – Multimedia Lab – Ghent University Barry Norton, Ontotext, UK Axel Polleres, Siemens, Australia Sebastian Speiser, Karlsruhe Institute of Technology, Germany Jürgen Umbrich, DERI Galway, Ireland María-Esther Vidal, Universidad Simón Bolívar, Venezuela Erik Wilde, EMC, USA Organizers Maria Maleshkova, Karlsruhe Institute of Technology Ruben Verborgh, iMinds – Multimedia Lab – Ghent University Thomas Steiner, Google Germany GmbH, Universitat Politècnica de Catalunya Steffen Stadtmüller, Karlsruhe Institute of Technology Pedro Szekely, University of Southern California
CfP: Services and Applications over Linked APIs and Data (ESWC workshop)
Services and Applications over Linked APIs and Data (ESWC workshop) http://salad2013.linkedservices.org/ SALAD ingredients Who? people from the Semantic Web, Web services, and REST communities What? novel ideas, concepts, and applications that combine Linked Data and Web APIs / services When? ESWC workshop on May 26/27, 2013 – submission deadline: March 4, 2013 How? an interactive workshop with lots of discussion, accepted paper presentations and keynote speaker Mike Amundsen (http://amundsen.com/blog/) Where? Montpellier, France at the ESWC conference (http://2013.eswc-conferences.org/) ⚖ Recipe Current developments on the Web have been marked by the increased use and popularity of Linked Data and Web APIs. However, these two technologies remain mostly disjunct in terms of developing solutions and applications in an integrated way. Therefore, we aim to explore the possibilities of facilitating a better integration of Web APIs and Linked Data, thus enabling the harvesting and provisioning of data through applications and services on the Web. In particular, we focus on investigating how resources exposed via Web APIs can be used together with Web semantic data, as means for enabling a shared use and providing a basis for developing rich applications on top. ✎ Shopping list The main goal of this workshop is to explore the possibilities of enabling a more integrated and automated use of Web APIs, given the context of the growing importance of Linked Data and applications, benefiting from the available resources. Relevant topics include: - integrated use of Linked Data and Web APIs - moving from individual APIs and data sets towards integrated solutions - differences and parallels between Linked Data and Web APIs - semantically discovering, searching, and browsing Web APIs - describing Web APIs and Linked Data - intelligent clients for Linked Data and APIs - methods for automatically dealing with failures in Web APIs - approaches for the creation of Web API directories The above list is not exhaustive and we therefore actively encourage participants to be creative. A final goal is to provide future initiatives with the devised ideas and visions to stimulate innovation in this research area. ♨ Preparation instructions Would you like to show your work at the SALAD workshop? Great! We offer several opportunities to participate in SALAD: - long papers: up to 8 pages (if you need more, just e-mail us at eswcsalad2...@gmail.com) - short papers: up to 4 pages - demos: up to 2 pages - food for thought: 1 page / slide / web page / image / movie Your submission can be posted through EasyChair (https://www.easychair.org/conferences/?conf=salad2013) or e-mailed (eswcsalad2...@gmail.com). Accepted papers will be published as CEUR workshop proceedings. Selected papers will be included in a separate ESWC workshop papers volume. ⌚ Preparation time Submission: March 4, 2013. Notification: April 1, 2013 Camera ready: April 15, 2013. Workshop: May 26/27, 2013. ⚘ Nutritional information Program committee Sudhir Agarwal, Stanford University, USA Jan Algermissen, NORD Software Consulting José Luis Ambite, University of Southern California, USA Mike Amundsen, Layer 7, USA Sven Casteleyn, Vrije Universiteit Brussel, Belgium Florian Daniel, University of Trento, Italy Peter Haase, fluidOps, Germany Armin Haller, CSIRO, Australia Andreas Harth, Karlsruhe Institute of Technology, Germany Katja Hose, Aalborg University, Denmark Geert-Jan Houben, TU Delft, Netherlands Jacek Kopecký, KMi, Open University, UK Erik Mannens, iMinds – Multimedia Lab – Ghent University Barry Norton, Ontotext, UK Axel Polleres, Siemens, Australia Sebastian Speiser, Karlsruhe Institute of Technology, Germany Jürgen Umbrich, DERI Galway, Ireland María-Esther Vidal, Universidad Simón Bolívar, Venezuela Erik Wilde, EMC, USA Organizers Maria Maleshkova, Karlsruhe Institute of Technology Ruben Verborgh, iMinds – Multimedia Lab – Ghent University Thomas Steiner, Google Germany GmbH, Universitat Politècnica de Catalunya Steffen Stadtmüller, Karlsruhe Institute of Technology Pedro Szekely, University of Southern California
Linked Data and Services are not going to work [CfP ESWC]
Hi there! Linked Data and Services are never going to work together… or are they? Your opinion is highly valued at the LAPIS workshop during the Extended Semantic Web Conference ESWC 2012 (May 27). Both regular (8 pages) and vision papers (4 pages) are welcome before March 9th. Also, if you have a wild idea (1 paragraph) or a discussion starter (1 paragraph), do not hesitate to submit! - Why? The Web has changed: services become resource-oriented APIs. We must react now. - Goal? Exploring the opportunities resource-oriented APIs offer, especially in combination with links. - For whom? Motivated researchers from the REST, Semantic Web, and Linked Data communities. - What? A truly interactive workshop, driven by constructive discussion and dialog. - Format?An inspiring day. Morning: talks and dialog. Afternoon: brainstorm and discussion Find out more at http://lapis2012.linkedservices.org/call-for-papers/ Best regards, the LAPIS organizing committee PS Not sure if you have time for a paper? Write down a wild idea or discussion starter in one paragraph and submit!
ontology for quality metrics?
Dear public-lod readers, Do you know an ontology for quality metrics? For example, I want to express the availability of a service, or the precision/recall of a result set. Other keywords could be: performance, correctness… I’ve performed several Web searches, but I only managed to find “quality metrics for ontologies” instead of the other way round. Any ideas? Thanks for your help! Best regards, -- Ruben Verborgh http://twitter.com/RubenVerborgh PhD Student at Multimedia Lab — IBBT / ELIS, Ghent University, Belgium Is your metadata trapped? http://freeyourmetadata.org/ Do your services need powerful descriptions? http://restdesc.org/
Re: ontology for quality metrics?
Hi Bernard, Thanks a lot for the pointer to the DQM vocabulary and also to the LOV search engine. I think DQM offers indeed what I need for the result set part. Great! Additionally, I’m looking for parameters (availability, performance, easy-of-use) to describe the server or actor that generates result sets. any clues? Best regards, -- Ruben Verborgh http://twitter.com/RubenVerborgh PhD Student at Multimedia Lab — IBBT / ELIS, Ghent University, Belgium Is your metadata trapped? http://freeyourmetadata.org/ Do your services need powerful descriptions? http://restdesc.org/ On 09 Jan 2012, at 09:48, Bernard Vatant wrote: Hi Ruben Have you checked http://labs.mondeca.com/dataset/lov/details/vocabularySpace_Quality.html ? http://labs.mondeca.com/dataset/lov/details/vocabulary_dqm.html might meet your needs. You can also try http://labs.mondeca.com/dataset/lov/search/#s=data%20quality Hope this helps ... and if you find something else, feel free to push it at http://labs.mondeca.com/dataset/lov/suggest/ Best Bernard 2012/1/9 Ruben Verborgh ruben.verbo...@ugent.be Dear public-lod readers, Do you know an ontology for quality metrics? For example, I want to express the availability of a service, or the precision/recall of a result set. Other keywords could be: performance, correctness… I’ve performed several Web searches, but I only managed to find “quality metrics for ontologies” instead of the other way round. Any ideas? Thanks for your help! Best regards, -- Ruben Verborgh http://twitter.com/RubenVerborgh PhD Student at Multimedia Lab — IBBT / ELIS, Ghent University, Belgium Is your metadata trapped? http://freeyourmetadata.org/ Do your services need powerful descriptions? http://restdesc.org/ -- Bernard Vatant Vocabularies Data Engineering Tel : + 33 (0)9 71 48 84 59 Skype : bernard.vatant Linked Open Vocabularies Mondeca 3 cité Nollez 75018 Paris, France www.mondeca.com Follow us on Twitter : @mondecanews
Services and the Semantic Web – it's complicated (ESWC 2012 workshop CfP)
* * * * * * * * * * * * * * * * * * * * * * * LAPIS 2012 Linked APIs for the Semantic Web ESWC 2012 workshop http://lapis2012.linkedservices.org/ * * * * * * * * * * * * * * * * * * * * * * * The Web as I envisioned it, we have not seen it yet. – Tim Berners-Lee Services and the Semantic Web: it's complicated. – anonymous gossip Semantic Web and APIs: an essential problem in need of a fresh look. – LAPIS 2012 mission === Challenge for Papers – What do *you* have to say about Linked APIs and the Semantic Web? === LAPIS 2012 in 5 questions - Why? The Web has changed: services become resource-oriented APIs. We must react now. Goal? Exploring the opportunities resource-oriented APIs offer, especially in combination with links. For whom? Motivated researchers from the REST, Semantic Web, and Linked Data communities. What? A truly interactive workshop, driven by constructive discussion and dialog. Format?An inspiring day. Morning: talks and dialog. Afternoon: brainstorm and discussion LAPIS 2012 in 5 bullets --- The main goal of the LAPIS workshop is to give birth to new ideas and visions, through presentations that encourage interaction and discussion. Topics of discussion include: - defining Linked APIs, what they could look like, and what role links can play - identifying the essential building blocks for enabling Linked APIs - pinpointing challenges to move from resource-oriented APIs towards Linked APIs - capturing added value of Linked APIs for the Semantic Web and REST communities - designing applications by connecting Linked Data and Linked APIs for reading and writing The above list is not exhaustive and we therefore actively encourage participants to be creative. LAPIS 2012 wants your submission Regular paper (8 pages) Regular papers focus on new ideas or technologies you have developed that relate to Linked APIs. We are very open-minded towards the workshop scope, and expect the same from you. Be original. Be creative. But most of all: be at least a little controversial – generate discussion. We're not looking for the next Big Invention. Workshop participants want to discover and to learn. Details: http://lapis2012.linkedservices.org/call-for-papers/ Vision paper (4 pages) Vision papers focus on creative ideas and concepts, even if there are no concrete results yet. Having more questions than answers can in fact be a plus… if you find the right questions. Details: http://lapis2012.linkedservices.org/call-for-papers/ Wild ideas and discussion starters (1 paragraph) Besides the traditional papers component, we would also like to run an experiment. We want your wildest ideas and discussion topics to make LAPIS 2012 an interactive workshop. Details: http://lapis2012.linkedservices.org/call-for-papers/ Motivated for this challenge? - Great! Visit us at http://lapis2012.linkedservices.org/ Your deadline is March 4th, 2012. LAPIS 2012 is organized by Craig Knoblock, Barry Norton, Ruben Verborgh, Sebastian Speiser, and Maria Maleshkova. LAPIS 2012 is driven by you, its participants. Come and discuss with us! http://lapis2012.linkedservices.org/
Re: [HTTP-range-14] Hyperthing: Semantic Web URI Validator (303, 301, 302, 307 and hash URIs)
Hi Yang, Great work. I tried looking up http://dbpedia.org/resource/Tim_Berners-Lee and was happy to see the result. Then, I got curious what http://dbpedia.org/page/Tim_Berners-Lee would return but unfortunately, it errors. Could you help me out? Thanks, Ruben On 17 Oct 2011, at 12:41, Yang Squared wrote: Following the HTTP-range-14 discussion, we developed a Semantic Web URIs Validator named Hyperthing which helps to publish the Linked Data. We particularly investigated what happens when we temporary and permnent redirect (e.g. 301 and 302 redirections) of a Semantic Web URI (303 and hash URI). http://www.hyperthing.org/ Hyperthing mainly functions for three purposes: 1) It determines if the requested URI identifies a Real World Object or a Web document; 2) It checks whether the URIs publishing method follows the W3C hash URIs and 303 URI practice; 3) It can be used to check the validity of the chains of the redirection between the Real World Object URIs and Document URIs to prevent the data publisher mistakenly redirecting between these two kinds. (e.g. it checks against redirection which include 301, 302 and 307) For more information please read Dereferencing Cool URI for the Semantic Web: What is 200 OK on the Semantic Web? http://dl.dropbox.com/u/4138729/paper/dereference_iswc2011.pdf Any suggestion is welcome.
Re: ANN: LDIF - Linked Data Integration Framework V0.1 released.
Hi Chris,
I've taken a look at your work and it is certainly interesting.
However, I have a couple questions with regarding the approach you have taken.
The example [1] shows that we need to create a specific mapping. But can we
call this semantic?
It is a configuration file which can only be understood by a specific tool. It
could as well have been XML or another format.
Why not choose to express the same things using existing, semantic predicates,
which can be understood by different tools and express actual knowledge?
And why not rely on existing ontologies that express relations semantically,
and reuse portable knowledge?
Example:
mp:Gene
r2r:sourcePattern ?SUBJ a genes:gene;
r2r:targetPattern ?SUBJ a smwcat:Gene.
could be
genes:gene owl:sameAs smwcat:Gene.
Not only does this have universally accepted semantics, it is also portable to
different situations. For example:
_:specializedGene rdfs:subClassOf genes:gene.
Another thing is that I do not agree with the pattern literals.
If we take a look at such a pattern:
?SUBJ a genes:gene,
we see there are a lot of implicit things here.
First, the prefix needs to be looked up using the r2r:prefixDefinitions
predicate. So a specific syntax (Turtle prefixes) is tied to a conceptual
model. I can imagine a lot of problems here. Clearly, r2r:prefixDefinitions is
some kind of functional property. But when are two prefixDefinitions the same?
Exact string comparison is not the answer.
But the bigger problem I'm having is with the variables. With the ?SUBJ
notation, you seem to add implicit support for universal quantification. This
last sentence clarifies the big issue: implicit. Variables are placeholders
identified by a certain name in a certain scope, but the name itself is
unimportant.
Concretely, ?SUBJ a genes:gene should mean the same as ?s a genes:gene.
Except that it doesn't.
Because now, ?SUBJ a smwcat:Gene is no longer meaningful. (Similar to the
above, how to define equality?)
And okay, you can argue that the scope is not the string, but the RDF document.
But what if I put the second statement in a different document? It's RDF,
right, or is this an application-specific configuration file?
And okay, we can say that the scope is the entity it belongs to. But then we
have a major problem:
mp:GeneID
r2r:mappingRef mp:Gene;
r2r:sourcePattern ?SUBJ genes:GeneId ?x;
r2r:targetPattern ?SUBJ smwprop:KeggGeneId ?'x'^^xsd:string;
GeneID also uses the ?SUBJ variable, but also has a relationship with Gene.
This puts them in the same scope. But clearly, the ?SUBJ from Gene and the
?SUBJ from GeneID should be different. This is a serious problem, which cannot
be solved rigorously, so the semantics will remain messy, since variables and
scope are not formally defined.
You can invalidate my arguments by saying that this RDF document is only meant
for a specific purpose etc. But why use RDF then, which is all about portable
semantics? See my question at the top of this e-mail.
As a solution, I would propose a W3C team submission which deals with
quantification properly: Notation3 [2]. They really got quantification right.
Look how much more semantic (and thus portable!) things become:
mp:hasPathway
a r2r:PropertyMapping;
r2r:mappingRef mp:Gene;
r2r:sourcePattern ?SUBJ genes:hasPathway ?x;
r2r:targetPattern ?SUBJ smwprop:IsInvolvedIn ?x . ?x
smwprop:Involves ?SUBJ;
becomes
{
?s genes:hasPathway ?x.
}
=
{
?s smwprop:IsInvolvedIn ?x
?x smwprop:Involves ?s.
}.
Note how the variables now have proper scoped and meaning. But even
quantification isn't necessary here:
genes:hasPathway rdfs:subPropertyOf smwprop:IsInvolvedIn.
genes:hasPathway rdfs:subPropertyOf smwprop:Involves.
This exactly matches the definition of a subproperty [3]: If a property P' is
a super-property of a property P, then all pairs of resources which are related
by P are also related by P'.
The major benefit of this is that everything can happen by general-purpose
Semantic Web reasoners, which rely on the *explicit* semantics present in the
document. The semantics are portable to different situations and contexts.
I'm eager to learn about the reasons of adaption of this custom vocabulary and
methodology, and the added value of this approach, instead of relying on
standards and widely accepted practices, and how your approach is portable to
other contexts.
[1]
http://www.assembla.com/code/ldif/git/nodes/ldif/ldif-singlemachine/src/main/resources/ldif/local/example/test2/mappings/ALL-to-Wiki.r2r.ttl?rev=176428845b9594e28a2f0362916de23cc821502c
[2] http://www.w3.org/TeamSubmission/n3/
[3] http://www.w3.org/TR/rdf-schema/#def-subproperty
Sincerely,
--
Ruben Verborgh
Ghent University - IBBT
Faculty of Engineering and Architecture
Department of Electronics and Information Systems (ELIS)
Multimedia Lab
Gaston Crommenlaan 8 bus 201
B-9050 Ledeberg-Ghent
Belgium
t: +32 9 33 14959
f
Re: ANN: LDIF - Linked Data Integration Framework V0.1 released.
Hi Chris, Thanks for the fast and detailed reply, it's a very interesting discussion. Indeed, there are several ways for mapping and identity resolution. But what strikes me is that people in the community seem to be insufficiently aware of the possibilities and performance of current reasoners. As you can see the data translation requires lots of structural transformations as well as complex property value transformations using various functions. All things where current logical formalisms are not very good at. Oh yes, they are. All needed transformations in your paper can be performed by at least two reasoners: cwm [1] and EYE [2] by using built-ins [3]. Include are regular expressions, datatype transforms… Frankly, every transform in the R2R example can be expressed as an N3 rule. If I as a application developer want to get a job done, what does it help me if I can exchange mappings between different tools that all don't get the job done? Because different tools can contribute different results, and if you use a common language and idiom, they all can work with the same data and metadata. more and more developers know SPARQL which makes it easier for them to learn R2R. The developers that know SPARQL is a proper subset of those that know plain RDF, which is what I suggest using. And even if rules are necessary, N3 is only a small extension of RDF. Benchmark we have the feeling that SPARQL engines are more suitable for this task then current reasoning engines due to their performance problems as well as problems to deal with inconsistent data. The extremely solid performance [4] of EYE is too little known. It can achieve things in linear time that other reasoners can never solve. But my main point is semantics. Why make a new system with its own meanings and interpretations, when there is so much to do with plain RDF and its widely known vocabularies (RDFS, OWL)? Ironically, a tool which contributes to the reconciliation of different RDF sources, does not use common vocabularies to express well-known relationships. Cheers, Ruben [1] http://www.w3.org/2000/10/swap/doc/cwm.html [2] http://eulersharp.sourceforge.net/ [3] http://www.w3.org/2000/10/swap/doc/CwmBuiltins [4] http://eulersharp.sourceforge.net/2003/03swap/dtb-2010.txt On 30 Jun 2011, at 10:51, Chris Bizer wrote: Hi Ruben, thank you for your detailed feedback. Of course it is always a question of taste how you prefer to express data translation rules and I agree that simple mappings can also be expressed using standard OWL constructs. When designing the R2R mapping language, we first analyzed the real-world requirements that arise if you try to properly integrate data from existing Linked Data on the Web. We summarize our findings in Section 5 of the following paper http://www.wiwiss.fu-berlin.de/en/institute/pwo/bizer/research/publications/ BizerSchultz-COLD-R2R-Paper.pdf As you can see the data translation requires lots of structural transformations as well as complex property value transformations using various functions. All things where current logical formalisms are not very good at. Others reasons why we choose to base the mapping language on SPARQL where that: 1. more and more developers know SPARQL which makes it easier for them to learn R2R. 2. we to be able to translate large amounts (billions of triples in the mid-term) of messy inconsistent Web data and from our experience with the BSBM Benchmark we have the feeling that SPARQL engines are more suitable for this task then current reasoning engines due to their performance problems as well as problems to deal with inconsistent data. I disagree with you that R2R mappings are not suitable for being exchanged on the Web. In contrast they were especially designed for being published and discovered on the Web and allow partial mappings from different sources to be easily combined (see paper above for details about this). I think your argument about the portability of mappings between different tools currently is only partially valid. If I as a application developer want to get a job done, what does it help me if I can exchange mappings between different tools that all don't get the job done? Also note, that we aim with LDIF to provide for identity resolution in addition to schema mapping. It is well known that identity resolution in practical setting requires rather complex matching heuristics (see Silk papers for details about different matchers that are usually employed) and identity resolution is again a topic where reasoning engines don't have too much to offer. But again, there are different ways and tastes about how to express mapping rules and identity resolution heuristics. R2R and Silk LSL are our approaches to getting the job done and we are of course happy if other people provide working solutions for the task of integrating and cleansing messy data from the Web of Linked Data
Re: ANN: LDIF - Linked Data Integration Framework V0.1 released.
Hi Chris, Sounds like a challenge indeed :) Thanks for bringing this to my attention. While we have a lot of experience with reasoning, we never tried to go to the billions. I contacted Jos De Roo, the author of the EYE reasoner, to see what would be possible. I think we might at least be able to perform some interesting stuff. Note however that performance is a separate issue from what I was saying before. No matter how good the LDIF Hadoop implementation will perform (and I am curious to find out!), for me, it doesn't justify creating a whole new semantics. The important thing here is that the R2R patterns can be generated from regular RDFS and OWL constructs (because these have a well-defined meaning!), while the other way round is difficult and impossible in general. If your (or anyone else's) software needs a different representation, why not create it from RDF documents that use those Semantic Web foundations instead of forcing people to write those instructions? Reuse is so important in our community, and while software will someday be able to bring a lot of data together, humans will always be responsible for getting things right at the very base. Cheers, Ruben On 30 Jun 2011, at 22:34, Chris Bizer wrote: Hi Ruben, Thanks for the fast and detailed reply, it's a very interesting discussion. Indeed, there are several ways for mapping and identity resolution. But what strikes me is that people in the community seem to be insufficiently aware of the possibilities and performance of current reasoners. Possibly. But luckily we are today in the position to just give it a try. So an idea with my Semantic Web Challenge hat on: Why not take the Billion Triples 2011 data set (http://challenge.semanticweb.org/) which consists of 2 billion triples that have been recently crawled from the Web and try to find all data in the dataset about authors and their publications, map this data to a single target schema and merge all duplicates. Our current LDIF in-memory implementation is not capable of doing this as 2 billion triples are too much data for it. But with the planned Hadoop-based implementation we are hoping to get into this range. It would be very interesting if somebody else would try to solve the task above using a reasoned-based approach and we could then compare the number of authors and publications identified as well as the duration of the data integration process. Anybody interested? Cheers, Chris
