http://www.openlinksw.com:443/blog/kidehen@openlinksw.com/blog/?id=1315 Daniel Lewis has published another post about OpenLink Data Spaces (ODS) functionality titled:A few new features in OpenLink Data Spaces, that exposes additional features (some hot out the oven). OpenLink Data Spaces (ODS) now officially supports: Attention Profiling Markup Language (APML). Meaning of a Tag (MOAT) in conjunction with Simple Knowledge Organisation System (SKOS) and Social-Semantic Cloud of Tags (SCOT). OAuth - an Open Authentication Protocol Which means that OpenLink Data Spaces support all of the main standards being discussed in the DataPortability Interest Group! APML Example: All users of ODS automatically get a dynamically created APML file, for example: APML profile for Kingsley Idehen The URI for an APML profile is: http://myopenlink.net/dataspace/&lt;ods-username&gt;/apml.xml Meaning of a Tag Example: All users of ODS automatically have tag cloud information embedded inside their SIOC file, for example: SIOC for Kingsley Idehen on the Myopenlink.net installation of ODS. But even better, MOAT has been implemented in the ODS Tagging System. This has been demonstrated in a recent test blog post by my colleague Mitko Iliev, the blog post comes up on the tag search: http://myopenlink.net/dataspace/imitko/weblog/Mitko%27s%20Weblog/tag/paris Which can be put through the OpenLink Data Browser: OpenLink Data Browser with Mitko Iliev’s Paris Blog Tag OAuth Example: OAuth Tokens and Secrets can be created for any ODS application. To do this: you can log in to MyOpenlink.net beta service, the Live Demo ODS installation, an EC2 instance, or your local installation then go to ‘Settings’ and then you will see ‘OAuth Keys’ you will then be able to choose the applications that you have instantiated and generate the token and secret for that app. Related Document (Human) Links OpenLink Data Spaces Official Page OpenLink Software Page OpenLink Data Spaces Wikipedia Page Attention Profiling Markup Language Project Website Meaning of a Tag Project Website Simple Knowledge Organisation Systems Project Website Social-Semantic Cloud of Tags Project Website OAuth Protocol Website DataPortability.org Website Semantically Interlinked Online Communities Project Website Remember (as per my most recent post about ODS), ODS is about unobtrusive fusion of Web 1.0, 2.0, and 3.0+ usage and interaction patterns. Thanks to a lot of recent standardization in the Semantic Web realm (e.g SPARQL), we are now employ the MOAT, SKOS, and SCOT ontologies as vehicles for Structured Tagging. Structured Tagging? This is how we take a key Web 2.0 feature (think 2D in a sense), bend it over, to create a Linked Data Web (Web 3.0) experience unobtrusively (see earlier posts re. Dimensions of Web). Thus, nobody has to change how they tag or where they tag, just expose ODS to the URLs of your Web 2.0 tagged content and it will produce URIs (Structured Data Object Identifiers) and a lnked data graph for your Tags Data Space (nee. Tag Cloud). ODS will construct a graph which exposes tag subject association, tag concept alignment / intended meaning, and tag frequencies, that ultimately deliver &quot;relative disambiguation&quot; of intended Tag Meaning (i.e. you can easily discern the taggers meaning via the Tags actual Data Space which is associated with the tagger). In a nutshell, the dynamics of relevance matching, ranking, and the like, change immensely without futile timeless debates about matters such as: What's the Linked Data value proposition? What's the Linked Data business model? XML vs RDF XQuery vs SPARQL What's the Semantic Web Killer application? We can just get on with demonstrating Linked Data value using what exists on the Web today. This is the approach we are deliberately taking with ODS. Related Items Stefano Mazzocch's response to Clay Shirky's 2005 talk titled: Ontology is Overrated: Links, Tags and Post-hoc Metadata Tom Gruber's post titled: Ontology of Folksonomy: A Mash-up of Apples and Oranges . Tip: This post is best viewed via an RDF aware User Agent (e.g. a Browser or Data Viewer). I say this because the permalink of this post is a URI in a Linked Data Space (My Blog) comprised of more data than meets the eye (i.e. what you see when you read this post via a Document Web Browser) :-) Sat, 09 Feb 2008 17:54:35 GMTVirtuoso Universal Server 08.03.3334Kingsley Uyi Idehenhttp://www.openlinksw.com:443/weblog/public/images/vbloglogo.gifhttp://www.openlinksw.com:443/blog/kidehen@openlinksw.com/blog/?id=1315I have seen the future and it's full of Linked Data! :-)8831 http://www.openlinksw.com:443/blog/kidehen@openlinksw.com/blog/?id=1315#4548http://www.openlinksw.com:443/blog/kidehen@openlinksw.com/blog/?id=1315#4548kidehen@openlinksw.comSun, 10 Feb 2008 17:16:52 GMTDan Brickley wrote: <br />This is looking good! <p> I think Oauth is going to be a very important piece of the puzzle here, when we deal with sharing non-public data. <p> One part is passive sharing of data to eg. friends and family. The other is accepting and servicing SPARQL queries where some but not all of the graphs being consulted are access controlled. <p> Have you looked at this at all? Any plans to share? >>> Dan, OAuth is the mechanism in ODS for sharing private data across Data Spaces with friends, family etc.. With the SPARQL Protocol being a Web Service, we are also going to be able to use OAuth (as you suggest) to protect specific Named Graphs. The final piece of fidelity we need to resolve, is how we combine this with Row Level security at Virtuoso's core as a Named Graph may still contain a dereferencable URI that provide a route to data that should be protected. This is where Row Level security provides the final level of protection.http://www.openlinksw.com:443/blog/kidehen@openlinksw.com/blog/?id=1315#4547http://www.openlinksw.com:443/blog/kidehen@openlinksw.com/blog/?id=1315#4547danbrickley@gmail.comSun, 10 Feb 2008 16:11:21 GMTThis is looking good! <p> I think Oauth is going to be a very important piece of the puzzle here, when we deal with sharing non-public data. <p> One part is passive sharing of data to eg. friends and family. The other is accepting and servicing SPARQL queries where some but not all of the graphs being consulted are access controlled. <p> Have you looked at this at all? Any plans to share?