Yeah, we might not have said too clearly that the whole thing is a prototype made for other hackers. The code has been through a long journey, so we know pretty well how the foundations will look, but there is quite a lot of work to get the server into a good shape security-wise. Then, we need to work a lot on Developer Experience and then User Experience. But we're attracting people now, which is good.
We're not married to any particular coin, but we have people working on stuff like that. One project alumni is working on Filecoin, and we are talking a lot with the people of Safecoin. I'm pretty sure we can have stuff like in near future.
Whoooah! No, it is not. DRM is fundamentally broken, so, that's not what we're aiming for. Indeed, if you trust your data with someone who is not worthy of your trust, then there is very little technology can do to fix that broken trust. Then, it becomes a really difficult social, psychological and legal problem, where technology can only play a very minor part.
So, what we're doing here is to ensure that you can store stuff on a web server you control. Then, the intelligence sits on your client, so the apps you use will be restricted by the security model of your device, and therefore should not send your data off without your consent.
WebID currently builds on OIDC (because we couldn't get browser makers support WebID-TLS, which is much simpler), but I think you'll find that it doesn't have the same problems: https://github.com/solid/webid...
But the server is pretty simple, and can and will be implemented in many different languages. People are working on a Go implementation too. The nice thing about JS is that much of the same logic is both on the server and the client side, and so it is actually the same code. That's pretty nice for consistency and cost of implementing it.
I'm myself not really impressed with the security of the Node.js landscape, but that's what we decided to do first.
Basically all the stuff around it. First, you have the permission stuff that allows you to share those pics with the people you want, without uploading it somewhere totally beyond any reasonable control. Then, others are welcome to provide apps around it, so your pics could be part of somebody's feed, like instagram, only, those pics are never uploaded to somebody else's server.
But overall, the server side is intended to be pretty simple.
So basically an old school web server with a permissions protocol slapped on top of it.
You make the stuff that we do sounds really simple, but yeah. That's pretty much it.:-)
But note that in spite of Tim having read-write capability in his first browser, it really never took off. And then we had this document web, when we also wanted a data web and an applications web. So, I guess we got the applications web, but just pretty primitive and constrained ones.
So, yeah, the server side is really very simple. It is like, the UNIX of the Web. But in terms of all the stuff that has been around for 25 years without taking off, there is really a lot to do...
These are very nice puff pieces claiming a lot of good intentions, but how does it work?
I can already create a calendar app -- or download one -- and control all my information by running it on my own web server. That is more hassle than I want.
Ah, but you are pinpointing it right there! It is more hassle than you want, why? If we could fix that problem, so that it wouldn't be more hassle to have it on your own webserver, then what would you do? And that's like iteration 1 of Solid, we're separating those apps from the data, so that you can have your data on your webserver, but you can use any calendar app you want. That way, companies will be competing to create the best apps, not to suck your data out of you. So, Solid is about making the infrastructure and the ecosystem to make sure that all those things aren't a hassle, they will be your preferred way to do it.
How does this new thing let me trust my data to code written by other people, that I probably never see, running on servers I don't control?
Right, good question, because that is the essence. But first of all, they are not running on a server you don't control, they are running on your client. So, Solid is doing a massive shift on where the intelligence will be. It will be mostly on the client. The server side will be pretty simple.
But the rest of the question is still interesting. It is a fairly long and intricate answer, but some of the short story here:
So, in the way it is working in browsers now, is the simple CORS restrictions. It is pretty broken, but it is what we have. So, we're making some hacks to identify web apps. And then, you can assign privileges to them. Since they are running on your device, the security of your browser applies to them.
Still, it doesn't mean that you can necessarily trust them, of course, but then, this is a social technology, so we could establish a Web of Trust around that. We're thinking a lot about that.
How will Berners-Lee's new company make enough money to pay employees and satisfy its venture-capital backers?
So, we don't know that yet. There are a few no-brainer business models of course, but we don't expect them to last long. But we have some really good people on the team, we'll figure it out.
It is certainly very convenient, when it works. It feels kinda strange to trust every financial detail of my life to the government, so whether it is good in a real sense is a question I'm very open to debate.
It does allow some very useful applications to be developed, with a very nice potential for streamlining interaction between government, citizens and private sector. This is actually very high on the government's agenda, which I'm happy about, because the bureaucracy is sometimes both heavy and heavy handed.
If it is done well, it could potentially enable citizens to simulate possible choices in their lives before they make a decision: "If I do $that, the taxes will be $this". It would also enable an improved public debate: now it is a lot of bickering of the style "if you raise $that_tax, it will adversly effect $that_group" "no, it won't, but not doing it is required by $that_group". They're just making things up, of course, the debate is usually completely devoid of facts. Soon, it might be possible to simulate those scenarios on a regular basis, so we get real facts on the table before making a decision.
Unfortunately, there's a long way from good ideas to actual implementations. I've been in meetings with the people who actually order these systems, and what can I say... Heads gotta roll to go anywhere... They're easily blinded by suits, and they have no idea what makes a robust system. So, for now, I'm not too confident it will happen, even though there are some very interesting ideas around.
That's not correct. Only the final sums are/were published after the affected person has had a chance to verify and correct the information. Here all his details were published, which is a severe violation of his privacy.
Yup, this really doesn't change so much. What is the true utility about the semantic web isn't syntax, it is the fact that you can query across very diverse data sources. If you have a look at the open linking data project page, that I linked in the story, you'll see a figure showing the data sources you can currently use, they are in the process of putting up endpoints for them, takes a while to do. It is like you'll have all that data in one large database, where you would give everyone a username and password so that they could maintain their own data. Which is something that just won't happen.
Well, the reason it is not XML is that XML is a tree model, which is usually a poor representation of the real world. RDF is a graph model. That said, you can use XSLT on RDF/XML, which is one serialisation of RDF. We're doing it, but it is something of a PITA. I think XSLT is easy enough to adapt, what I think we will be looking into for the future is to work on an XPath replacement to navigate a subtree of the graph called a concise bounded description. If we get somewhere with that, it may be a candidate for standardisation.
Yeah, performance issues has been a big problem, and it has driven many early adopters away from it. I've had some really bad performance problems myself. However, academics generally agree that it is because most of the implementation and tuning experience people have are with relational databases, the graph model of RDF are not among the hard problems to solve, everything is pretty much known, it is just getting the theory into running code, and performance will be as good as with relational databases.
Oracle, Franz and OpenLink (the latter having a free software version), are about to show that in practice. I think we're getting there.
And people have been doing really large databases with great performance on in-house applications. I haven't seen them live, but I have read their papers.
So, it is an important point that you raise, but I think it has a solution in near future too.
Hehe, well, yeah, FOAF's been around for ages, it predates pretty much the whole social networking craze. But the XML thing is kinda arbitrary, it is just one of several ways to write RDF. I don't really write RDF as XML by hand anymore, except for that single file. I might use RDF/XML if it is generated, if I hand-write, I use Turtle.
Anyway, FOAF + SIOC + Policy Aware Web comprises pretty good solutions to the data portability and privacy considerations people have been screaming about lately.
There's not much shadowy about Kingsley. He is a very nice guy who does a lot of good things. He is very visible and very active in the community, also on IRC.
Glad you're working on it. But I can't agree Google is doing so good. One of my customers is a bunch of librarians, and they see a lot of people seeking advice on how to find information. The information is out there, but it is so hard getting the keywords right that people can't actually do it. So, they turn to skilled information gatherers, i.e. librarians, who, supported by people with extensive domain knowledge, can point them the right way. This has shown us that pure text search is overrated, people don't really know what they're missing. The search is only the starting point, from there it is faceted navigation with reasoning support that's the way to go!:-)
Yup, that's a gross oversimplification. SQL is not very well suited for the kind of stuff we're talking about. It is very constrained, and doesn't help you in large data integration problems. There are a lot of money in huge data integration problems. And that's where most of the money up to now has been, big industry merges, high-level execs realising their SQL doesn't cut it. And that's why Oracle is on board. But SPARQL is most interesting when people are exposing data on the open web, and we're starting to exploit those data.
Well, no, it hasn't changed your life just yet, but you could check out a few links in the story, there is a lot of potential there. I'm not going to run off on conspiracy theories, but it is pretty clear that many big players likes to keep things under locks, that's a hurdle that makes this take slightly longer.
In my submission, I gave an example query, which you can run at DBPedia with their standard prefixes:
SELECT ?name ?birth ?death ?person WHERE { ?person skos:subject ;
dbpedia2:birth ?birth ;
foaf:name ?name . OPTIONAL { ?person dbpedia2:death ?death } FILTER (?birth "1945-01-01"^^xsd:date) . } ORDER BY ?name"
What this says is "give me the name, birth data and death date of a person that has the following properties: It is a computer scientist, who has a birth day and a name and optionally a death date, then filter based on the date and order it by name.
There are now billions of such stuff you can query, and if you're open minded, it could indeed change your life.
Oh, it is actually really simple. See, first thing is that you link two documents. That's good old HTML. Then, you realise that you would want to link anything. Like persons. So, you give those persons a URI. You can't retrieve a person over the Internet, that's why it is a URI, not a URL, but you can get a description of the person. And then you realise that you want to say something about the nature of the relationship. So you put in a third URI that says something about the relationship. For example that the person knows that other person, or is his son, or something.
Well, if his first point was correct, the web wouldn't exist at all. Allthough there are lengthy fights in for example the HTML area, and it took a while to get RDF on a firm footing, semweb standardisation is actually moving pretty quickly now that we have the foundations.
His second point is just a common misconceptions and FAQs. It doesn't require that people does that.
I have just accepted a position with a consultancy that does a fair amount of work for those cut-throat businesses. And they are interested, very interested, in fact. Which is also why Oracle, IBM, HP, even Microsoft is interested.
Typical use case for them is: So, you bought your competitor, and each of the companies sit on big valuable databases that are incompatible. You have huge data integration problem that needs solving fast. So, throw in an RDF model, which is actually a pretty simple model. Use the SPARQL query language. Now all employees have access to the data they need. Problem solved. Lots of money saved. Good.
But this is not part of the open web, you say? Indeed, you're right. So, Semantic Web technologies have allready succeeded, but not on the open web. And since I'm such an idealist, I want it on the open web. So, the blog still has a valid point.
We need to make compelling reasons why they should put (some) data on the open web. It isn't easy, but then, let TimBL tell you it wasn't easy to get them on the web in the first place. It is not very different, actually. The main approach to this is capitalise on network effects. There is a lot of public information, and we need to start with that.
So, partly, that's what I'll do. We have emergent use cases, and that's the evil part of cut-throat business. You don't talk about those before they happen. So, sorry about that. I think it will be very compelling, but it'll take a few years. If you're the risk-averse kinda developer who first and foremost has a family to feed, then I understand that you don't want to risk anything, and you can probably jump on the bandwagon a couple of years from now, having lost relatively little.
But if you, like me, like to live on the edge, and doesn't mind taking risks doing things that of course might fail, then I think semweb is one of most interesting things right now.
They are two quite different things. Microformats and tagging is for making data available and simple one-data-source applications. And it is very useful for that. The Semantic Web is a consistent data model and more elaborate data access methods for larger things that involve multiple data sources.
Also, GRDDL has just made microformats a part of the Semantic Web, and I have just created a system to marry taxonomies and folksonomies, (i.e. big controlled vocabularies and tags).
There is no conflict here. People can safely use microformats for a lot of stuff (even when it doesn't make sense!:-) ) and tags are more useful than not annotate. It will all be a part of the Semantic Web, but microformats and tags far from realise the goals of the Semantic Web.
Clearly, you haven't seen anything of what the academics have been doing. Of course, people brought along those lessons learned from the failures of HTML, which was partly because the data model was not clear, partly because it was indeed much to easy to abuse. Academics have of course discussed this at length. Indeed, some approaches have been rather academic, such as building everything on big PGP-based trust networks, but others are very practical.
Right now, we're building semweb based trust metrics for email. I have allready plugins for SpamAssassin and Qpsmtpd, though they are for small scale stuff, we have like 25 million profiles we could use.
For example, your concerns about digital camera reviews are addressed by Revyu.
All in all, there is a lot of stuff going on in this area, both big forward-looking academic projects and practical implementations.
Of course, the failure of the meta element is one of the most important lessons learned, and one of the reasons that semweb geeks like myself aren't all that fond of microformats.
There's a company called Segala and their main business is to use semweb technologies to make people tell the truth. And I think they are doing a good job.
Indeed, the Web 2.0 thing is really a small, incremental change. Write-web was really in TimBL's ideas from the beginning. Collaboration too. Arguably, the application web is a bigger step up.
But Web 2.0 is distinctly different from the Semantic Web. The Semantic Web is about structuring data on a global level and allow queries on them. There is a lot of structured data out there (in backend databases, XML trees, etc), and making them available in a consistent data model, the Semantic Web is here.
The big use cases are bigger mashups. Like now, people are doing some mashups. Like for example putting weather symbols on google maps and get weather forecasts. That's trivial on the Semantic Web, you would do that without any programmer, you just say that "this weather symbol" is an icon, and that's it, an ontology aware browser would just do it.
Programmers are using a lot of time on creating simple mashups, but semweb mashups typically involves little effort to include like 10 different data sources.
Slashdot Mirror
Yeah, we might not have said too clearly that the whole thing is a prototype made for other hackers. The code has been through a long journey, so we know pretty well how the foundations will look, but there is quite a lot of work to get the server into a good shape security-wise. Then, we need to work a lot on Developer Experience and then User Experience. But we're attracting people now, which is good.
We're not married to any particular coin, but we have people working on stuff like that. One project alumni is working on Filecoin, and we are talking a lot with the people of Safecoin. I'm pretty sure we can have stuff like in near future.
This design seems like DRM for personal data.
Whoooah! No, it is not. DRM is fundamentally broken, so, that's not what we're aiming for. Indeed, if you trust your data with someone who is not worthy of your trust, then there is very little technology can do to fix that broken trust. Then, it becomes a really difficult social, psychological and legal problem, where technology can only play a very minor part.
So, what we're doing here is to ensure that you can store stuff on a web server you control. Then, the intelligence sits on your client, so the apps you use will be restricted by the security model of your device, and therefore should not send your data off without your consent.
WebID currently builds on OIDC (because we couldn't get browser makers support WebID-TLS, which is much simpler), but I think you'll find that it doesn't have the same problems: https://github.com/solid/webid...
But the server is pretty simple, and can and will be implemented in many different languages. People are working on a Go implementation too. The nice thing about JS is that much of the same logic is both on the server and the client side, and so it is actually the same code. That's pretty nice for consistency and cost of implementing it.
I'm myself not really impressed with the security of the Node.js landscape, but that's what we decided to do first.
But overall, the server side is intended to be pretty simple.
So basically an old school web server with a permissions protocol slapped on top of it.
You make the stuff that we do sounds really simple, but yeah. That's pretty much it. :-)
But note that in spite of Tim having read-write capability in his first browser, it really never took off. And then we had this document web, when we also wanted a data web and an applications web. So, I guess we got the applications web, but just pretty primitive and constrained ones.
So, yeah, the server side is really very simple. It is like, the UNIX of the Web. But in terms of all the stuff that has been around for 25 years without taking off, there is really a lot to do...
These are very nice puff pieces claiming a lot of good intentions, but how does it work?
I can already create a calendar app -- or download one -- and control all my information by running it on my own web server. That is more hassle than I want.
Ah, but you are pinpointing it right there! It is more hassle than you want, why? If we could fix that problem, so that it wouldn't be more hassle to have it on your own webserver, then what would you do? And that's like iteration 1 of Solid, we're separating those apps from the data, so that you can have your data on your webserver, but you can use any calendar app you want. That way, companies will be competing to create the best apps, not to suck your data out of you. So, Solid is about making the infrastructure and the ecosystem to make sure that all those things aren't a hassle, they will be your preferred way to do it.
How does this new thing let me trust my data to code written by other people, that I probably never see, running on servers I don't control?
Right, good question, because that is the essence. But first of all, they are not running on a server you don't control, they are running on your client. So, Solid is doing a massive shift on where the intelligence will be. It will be mostly on the client. The server side will be pretty simple.
But the rest of the question is still interesting. It is a fairly long and intricate answer, but some of the short story here:
So, in the way it is working in browsers now, is the simple CORS restrictions. It is pretty broken, but it is what we have. So, we're making some hacks to identify web apps. And then, you can assign privileges to them. Since they are running on your device, the security of your browser applies to them.
Still, it doesn't mean that you can necessarily trust them, of course, but then, this is a social technology, so we could establish a Web of Trust around that. We're thinking a lot about that.
How will Berners-Lee's new company make enough money to pay employees and satisfy its venture-capital backers?
So, we don't know that yet. There are a few no-brainer business models of course, but we don't expect them to last long. But we have some really good people on the team, we'll figure it out.
It is certainly very convenient, when it works. It feels kinda strange to trust every financial detail of my life to the government, so whether it is good in a real sense is a question I'm very open to debate. It does allow some very useful applications to be developed, with a very nice potential for streamlining interaction between government, citizens and private sector. This is actually very high on the government's agenda, which I'm happy about, because the bureaucracy is sometimes both heavy and heavy handed. If it is done well, it could potentially enable citizens to simulate possible choices in their lives before they make a decision: "If I do $that, the taxes will be $this". It would also enable an improved public debate: now it is a lot of bickering of the style "if you raise $that_tax, it will adversly effect $that_group" "no, it won't, but not doing it is required by $that_group". They're just making things up, of course, the debate is usually completely devoid of facts. Soon, it might be possible to simulate those scenarios on a regular basis, so we get real facts on the table before making a decision. Unfortunately, there's a long way from good ideas to actual implementations. I've been in meetings with the people who actually order these systems, and what can I say... Heads gotta roll to go anywhere... They're easily blinded by suits, and they have no idea what makes a robust system. So, for now, I'm not too confident it will happen, even though there are some very interesting ideas around.
That's not correct. Only the final sums are/were published after the affected person has had a chance to verify and correct the information. Here all his details were published, which is a severe violation of his privacy.
Yup, this really doesn't change so much. What is the true utility about the semantic web isn't syntax, it is the fact that you can query across very diverse data sources. If you have a look at the open linking data project page, that I linked in the story, you'll see a figure showing the data sources you can currently use, they are in the process of putting up endpoints for them, takes a while to do. It is like you'll have all that data in one large database, where you would give everyone a username and password so that they could maintain their own data. Which is something that just won't happen.
Well, the reason it is not XML is that XML is a tree model, which is usually a poor representation of the real world. RDF is a graph model. That said, you can use XSLT on RDF/XML, which is one serialisation of RDF. We're doing it, but it is something of a PITA. I think XSLT is easy enough to adapt, what I think we will be looking into for the future is to work on an XPath replacement to navigate a subtree of the graph called a concise bounded description. If we get somewhere with that, it may be a candidate for standardisation.
Oracle, Franz and OpenLink (the latter having a free software version), are about to show that in practice. I think we're getting there.
And people have been doing really large databases with great performance on in-house applications. I haven't seen them live, but I have read their papers.
So, it is an important point that you raise, but I think it has a solution in near future too.
Mainly because trees are very bad at describing many real world things. If you want trees, use XML and XQuery, but it won't get you very far, IMHO.
RDF is a graph model, much more powerful, and something that can truly scale.
Anyway, FOAF + SIOC + Policy Aware Web comprises pretty good solutions to the data portability and privacy considerations people have been screaming about lately.
There's not much shadowy about Kingsley. He is a very nice guy who does a lot of good things. He is very visible and very active in the community, also on IRC.
Glad you're working on it. But I can't agree Google is doing so good. One of my customers is a bunch of librarians, and they see a lot of people seeking advice on how to find information. The information is out there, but it is so hard getting the keywords right that people can't actually do it. So, they turn to skilled information gatherers, i.e. librarians, who, supported by people with extensive domain knowledge, can point them the right way. This has shown us that pure text search is overrated, people don't really know what they're missing. The search is only the starting point, from there it is faceted navigation with reasoning support that's the way to go! :-)
Yup, that's a gross oversimplification. SQL is not very well suited for the kind of stuff we're talking about. It is very constrained, and doesn't help you in large data integration problems. There are a lot of money in huge data integration problems. And that's where most of the money up to now has been, big industry merges, high-level execs realising their SQL doesn't cut it. And that's why Oracle is on board. But SPARQL is most interesting when people are exposing data on the open web, and we're starting to exploit those data.
Well, no, it hasn't changed your life just yet, but you could check out a few links in the story, there is a lot of potential there. I'm not going to run off on conspiracy theories, but it is pretty clear that many big players likes to keep things under locks, that's a hurdle that makes this take slightly longer.
In my submission, I gave an example query, which you can run at DBPedia with their standard prefixes:
SELECT ?name ?birth ?death ?person WHERE
{ ?person skos:subject ;
dbpedia2:birth ?birth ;
foaf:name ?name .
OPTIONAL { ?person dbpedia2:death ?death }
FILTER (?birth "1945-01-01"^^xsd:date) . }
ORDER BY ?name"
What this says is "give me the name, birth data and death date of a person that has the following properties:
It is a computer scientist, who has a birth day and a name and optionally a death date, then filter based on the date and order it by name.
There are now billions of such stuff you can query, and if you're open minded, it could indeed change your life.
Oh, it is actually really simple. See, first thing is that you link two documents. That's good old HTML. Then, you realise that you would want to link anything. Like persons. So, you give those persons a URI. You can't retrieve a person over the Internet, that's why it is a URI, not a URL, but you can get a description of the person. And then you realise that you want to say something about the nature of the relationship. So you put in a third URI that says something about the relationship. For example that the person knows that other person, or is his son, or something.
so
<http://www.kjetil.kjernsmo.net/foaf#me> <http://xmlns.com/foaf/0.1/knows> <http://www.w3.org/People/Berners-Lee/card#i>
simply says that I know timbl. I hope you're less stumped than you used to be.
If you grok this, you've grokked 90% of RDF.
His second point is just a common misconceptions and FAQs. It doesn't require that people does that.
I have just accepted a position with a consultancy that does a fair amount of work for those cut-throat businesses. And they are interested, very interested, in fact. Which is also why Oracle, IBM, HP, even Microsoft is interested.
Typical use case for them is: So, you bought your competitor, and each of the companies sit on big valuable databases that are incompatible. You have huge data integration problem that needs solving fast. So, throw in an RDF model, which is actually a pretty simple model. Use the SPARQL query language. Now all employees have access to the data they need. Problem solved. Lots of money saved. Good.
But this is not part of the open web, you say? Indeed, you're right. So, Semantic Web technologies have allready succeeded, but not on the open web. And since I'm such an idealist, I want it on the open web. So, the blog still has a valid point.
We need to make compelling reasons why they should put (some) data on the open web. It isn't easy, but then, let TimBL tell you it wasn't easy to get them on the web in the first place. It is not very different, actually. The main approach to this is capitalise on network effects. There is a lot of public information, and we need to start with that.
So, partly, that's what I'll do. We have emergent use cases, and that's the evil part of cut-throat business. You don't talk about those before they happen. So, sorry about that. I think it will be very compelling, but it'll take a few years. If you're the risk-averse kinda developer who first and foremost has a family to feed, then I understand that you don't want to risk anything, and you can probably jump on the bandwagon a couple of years from now, having lost relatively little.
But if you, like me, like to live on the edge, and doesn't mind taking risks doing things that of course might fail, then I think semweb is one of most interesting things right now.
Also, GRDDL has just made microformats a part of the Semantic Web, and I have just created a system to marry taxonomies and folksonomies, (i.e. big controlled vocabularies and tags).
There is no conflict here. People can safely use microformats for a lot of stuff (even when it doesn't make sense! :-) ) and tags are more useful than not annotate. It will all be a part of the Semantic Web, but microformats and tags far from realise the goals of the Semantic Web.
Right now, we're building semweb based trust metrics for email. I have allready plugins for SpamAssassin and Qpsmtpd, though they are for small scale stuff, we have like 25 million profiles we could use.
For example, your concerns about digital camera reviews are addressed by Revyu.
All in all, there is a lot of stuff going on in this area, both big forward-looking academic projects and practical implementations.
There's a company called Segala and their main business is to use semweb technologies to make people tell the truth. And I think they are doing a good job.
But Web 2.0 is distinctly different from the Semantic Web. The Semantic Web is about structuring data on a global level and allow queries on them. There is a lot of structured data out there (in backend databases, XML trees, etc), and making them available in a consistent data model, the Semantic Web is here.
The big use cases are bigger mashups. Like now, people are doing some mashups. Like for example putting weather symbols on google maps and get weather forecasts. That's trivial on the Semantic Web, you would do that without any programmer, you just say that "this weather symbol" is an icon, and that's it, an ontology aware browser would just do it.
Programmers are using a lot of time on creating simple mashups, but semweb mashups typically involves little effort to include like 10 different data sources.