SA-REST - Revision history

AjithRanabahu: Changed the top to reflect the latest version

2011-04-20T15:12:11Z

Changed the top to reflect the latest version

AjithRanabahu: /* Data Mediation and Mediatability */

2010-01-02T03:01:53Z

‎Data Mediation and Mediatability

AjithRanabahu: /* Faceted Search */

2010-01-02T03:01:07Z

‎Faceted Search

AjithRanabahu: /* SA-REST in a nutshell */ A quick addition to indicate that SA-REST is not only about APIs

2009-10-19T21:12:19Z

‎SA-REST in a nutshell: A quick addition to indicate that SA-REST is not only about APIs

AjithRanabahu: more text changes

2009-09-19T17:01:47Z

more text changes

AjithRanabahu: correcting wrong markup

2009-09-19T16:47:46Z

correcting wrong markup

AjithRanabahu: making some comments invisible

2009-09-19T16:41:52Z

making some comments invisible

Kgomadam: /* domain-rel */

2009-03-05T09:28:10Z

‎domain-rel

Kgomadam: /* domain-rel */

2009-03-05T09:27:46Z

‎domain-rel

AjithRanabahu: /* Multivalued Properties */

2009-03-05T09:21:59Z

‎Multivalued Properties

← Older revision		Revision as of 15:12, 20 April 2011
Line 1:		Line 1:
		+	<span style="color:red">Note : This is a draft version of SA-REST. The latest (and active) version is the [http://www.w3.org/Submission/SA-REST/ W3C Member Submission] </span>
		+
		+	----
		+
		+
	SA-REST is a simple and open microformat for enhancing Web resources with additional semantic information.		SA-REST is a simple and open microformat for enhancing Web resources with additional semantic information.
	In addition to HTML and XHTML, the SA-REST approach can also be used to enrich Atom, RSS, and arbitrary XML. SA-REST is one of several open microformat standards.		In addition to HTML and XHTML, the SA-REST approach can also be used to enrich Atom, RSS, and arbitrary XML. SA-REST is one of several open microformat standards.

@@ Line 55: / Line 55: @@
 ===Data Mediation and Mediatability===
 The importance of enabling easier approaches to data mediation has been well understood. In the context of mashups this is even more important, largely due to the fact that often developers are faced with the burden of handling data at the client side. SA-REST will address this issue in two ways
-*'''Adopting XML annotation from SAWSDL''': This will allow us to add the lifting and lowering transformations to data elements as a part of the API description. Information about SAWSDL lifting and lowering can be found in the[http://www.w3.org/TR/sawsdl/#annotateXSD SAWSDL spec on schema annotations]. There is a small catch that we have to address here. In the WSDL world, data exchange was XML de-facto. However, in the RESTful environment, developers can use many formats such as JSON, GData, RSS. It will be interesting to investigate this as a part of the SA-REST effort.
+*'''Adopting XML annotation from SAWSDL''': This will allow us to add the lifting and lowering transformations to data elements as a part of the API description. Information about SAWSDL lifting and lowering can be found in the [http://www.w3.org/TR/sawsdl/#annotateXSD SAWSDL spec on schema annotations]. There is a small catch that we have to address here. In the WSDL world, data exchange was XML de-facto. However, in the RESTful environment, developers can use many formats such as JSON, GData, RSS. It will be interesting to investigate this as a part of the SA-REST effort.
 *'''Mediatability''': [http://knoesis.wright.edu/students/gomadam/publications/GRRVS--ICSC08.pdf Mediatability] is a measure of the estimated human effort for performing data mediation manually. Having additional annotations can significantly help us in computing the mediatability. Even when automatic mediation is not possible, knowing how hard or easy the mediation between two services can definitely help developers in choosing services for their mashups.

@@ Line 50: / Line 50: @@
 Addition of meta-data to capture the various facets of APIs (their functionality, the message types they support, clientside bindings, protocol) can allow for better searching. The results of
-one such framework [http://apihut.dooduh.com APIHut] is presented in [http://knoesis.wright.edu/library/download/GRNVS-facetedAPISearch-ICWS08.pdf Faceted Search for APIs]. We also present
+one such framework [http://knoesis.wright.edu/research/srl/projects/apihut/ APIHut] is presented in [http://knoesis.wright.edu/library/download/GRNVS-facetedAPISearch-ICWS08.pdf Faceted Search for APIs]. We also present
 our initial evaluation of precision and recall metrics. SA-REST can improve faceted search in a significant manner. Using known techniques of GRDDL and XSLT, one can extract RDF representations of APIs. This can then be indexed and searched upon.

@@ Line 28: / Line 28: @@
 <!-- Change this. We can remove this completely, if we can capture a very good description at the beginning. -->
-SA-REST is a microformat to add additional meta-data to REST API descriptions in HTML and XHTML. Developers can directly embed meta-data from various models such an ontology, taxonomy or a tag cloud into their API descriptions. The embedded meta-data can be used to improve search (for example: perform faceted search for APIs), data mediation (in conjunction with XML annotation) as well as help in easier integration of services to create mashups.
+SA-REST is a microformat to add additional meta-data to (but not limited to) REST API descriptions in HTML and XHTML. Developers can directly embed meta-data from various models such an ontology, taxonomy or a tag cloud into their API descriptions. The embedded meta-data can be used to improve search (for example: perform faceted search for APIs), data mediation (in conjunction with XML annotation) as well as help in easier integration of services to create mashups.
 ===Background===

@@ Line 13: / Line 13: @@
 ===Current mashup tools and technologies===
-This section changes as well to talk about limitation in APIs and how SA-REST can address this. Add a blog example.
+<!-- This section changes as well to talk about limitation in APIs and how SA-REST can address this. Add a blog example.-->
 Although mashups fully embrace the idea of customization on the Web, read-write is another story. The complexity of application development using javascript makes it hard for average developers to create new mashups and to customize the existing ones. To solve this problem, several companies are developing tools for mashup creation that require little or no programming knowledge. These tools, exemplified by Yahoo! pipes, IBM's QEDwiki and Google's Mashup Editor, facilitate the selection of some number of RESTful Web services or other Web resources and chain them together by piping one service's output into the next service's input while filtering content and making slight format changes.
 ====Limitations====
-One of the main drawbacks of the current state of the art is the lack of support for interoperability, especially that of data. Since most these deal with services internal to the company that created them (for example, Google Mashup Editor can use Google Maps) or to services that have standard types of outputs such as RSS or Atom (Yahoo! Pipes), the problem of interop does not seem to arise.
+One of the main drawbacks of the current state of the art is the lack of support for interoperability, especially that of data. Since most of the existing tools limit their support to services internal to the specific vendor that created them (for example, Google Mashup Editor has a complete abstraction of Google Maps service) or to services that have standard types of outputs such as RSS or Atom (Yahoo! Pipes), the problem of interop is not highlighted.
 Another drawback of the current approach to mashups is the complexity of their development itself. Frameworks like Pipes that do not require any programming have limited capabilities. Google
-Mashup Editor has a steeper learning curve and can do much more than Yahoo! Pipes. The need to be proficient in languages such as javascript is mandatory to create more complex mashups.
+Mashup Editor has a steeper learning curve and can do much more than Yahoo! Pipes. However the need to be proficient in languages such as javascript is mandatory to create more complex mashups.
-We identify two types of this complexity
+We identify two aspects of this complexity
 * Visual: Complexity arising out of the need to create intuitive visual elements and handle various events relating to them
-* Data: Complexity arising due to heterogeneous in data schemas and formats.
+* Data: Complexity arising due to heterogeneity in data schemas and formats.
 ===SA-REST in a nutshell===
 <!-- Change this. We can remove this completely, if we can capture a very good description at the beginning. -->

@@ Line 140: / Line 140: @@
 '''Multi-domain domain-rel example 2'''
 <pre><nowiki><span class="domain-rel" title="http://apihut.com/schemas/socialnetworking#socialnetworks http://apihut.com/schemas/economy#recession"> One often wonders the future of
-advertisement driven Web applications in the current economic scenario. For example, social networking applications such as...</span>
+advertisement driven Web applications in the current economic scenario. For example, social networking applications such as...</span></nowiki></pre>
 ===sem-rel===
-The
+The sem-rel property will capture the semantics of a link. This evolves from the popular rel tag. An application of sem-rel would be to describe
-sem-rel: Sem-rel element will capture the semantics of a link. This evolves from the popular rel tag. An application of sem-rel would be to describe
 a data model that is captured in a XSD. The primary purpose of the sem-rel tag is to allow developers to add "top level annotation" to schemas that are third party.
 <pre><nowiki> <a href="http://foo.xsd" sem-rel="http://taxonomy.org/computerscience#firstname"> This is the input schema</a> </nowiki></pre>
-===sem-rel===
+<pre><nowiki> <a href="www.teachmegooglemaps.com" class="sem-rel" title="http://apihut.com/taxonomies/domainClassification.rdf#maps"> Learn Google Maps</nowiki></pre>
-−
-When an author of a resource links to another resource, the semantic information of the ''linked resource'' can be captured using the sem-rel property. The sem-rel property also allows
-enumeration within the title attribute. It is used in conjunction with the a attribute.
-−
 <pre><nowiki> <a href="www.teachmegooglemaps.com" class="sem-rel" title="http://apihut.com/taxonomies/domainClassification.rdf#maps"> </nowiki></pre>
 ===sem-class===

@@ Line 10: / Line 10: @@
 ==Introduction==
-Replace this with a need for additional semantic annotation for Web resources. Highlight Web APIs as an example, not the only effect.
+<!-- Replace this with a need for additional semantic annotation for Web resources. Highlight Web APIs as an example, not the only effect. -->
 ===Current mashup tools and technologies===
@@ Line 25: / Line 25: @@
 ===SA-REST in a nutshell===
-Change this. We can remove this completely, if we can capture a very good description at the beginning.
+<!-- Change this. We can remove this completely, if we can capture a very good description at the beginning. -->
 SA-REST is a microformat to add additional meta-data to REST API descriptions in HTML and XHTML. Developers can directly embed meta-data from various models such an ontology, taxonomy or a tag cloud into their API descriptions. The embedded meta-data can be used to improve search (for example: perform faceted search for APIs), data mediation (in conjunction with XML annotation) as well as help in easier integration of services to create mashups.
@@ Line 41: / Line 41: @@
 ==Usage Scenarios==
-Need to write this along the style of microformats.org wiki.
+<!-- Need to write this along the style of microformats.org wiki. -->
 ===Faceted Search===

@@ Line 124: / Line 124: @@
 '''Simple domain-rel example'''
-<pre><nowiki><span class="domain-rel" title="http://apihut.com/schemas/socialnetworking#socialnetworks> The growing trend of "liking" has recently caught a lot of attention of both network users as well as developers.</span></nowiki></pre>
+<pre><nowiki><span class="domain-rel" title="http://apihut.com/schemas/socialnetworking#socialnetworks> The growing trend of "liking" has recently caught a lot of attention of both network
 The example below illustrates a multi-domain scenario where the domain contexts can be separated in the content. This annotation is desirable when a resources (such as integrated feeds) that draw content from multiple sources are created.
 '''Multi-domain domain-rel example 1'''
-<pre><nowiki><span class="domain-rel" title="http://apihut.com/schemas/socialnetworking#socialnetworks> The growing trend of "liking" has recently caught a lot of attention of both network users as well as developers...</span>
+<pre><nowiki><span class="domain-rel" title="http://apihut.com/schemas/socialnetworking#socialnetworks> The growing trend of "liking" has recently caught a lot of attention of both network
 <span class="domain-rel" title="http://apihut.com/schemas/economy#banking"> I also came across this interesting discussion on bailout that talked about nationalization of banks</span>

@@ Line 147: / Line 147: @@
 <pre><nowiki> <a href="http://foo.xsd" sem-rel="http://taxonomy.org/computerscience#firstname"> This is the input schema</a> </nowiki></pre>
-===domain-rel===
+===sem-rel===
-captures the domain of the current api. It can applied either as a block or an elemental markup.
-<pre><nowiki> <body domain-rel="http://apihut.com/taxonomies/domainClassification.rdf#maps"> </nowiki></pre>
+When an author of a resource links to another resource, the semantic information of the ''linked resource'' can be captured using the sem-rel property. The sem-rel property also allows
-The above example can also be reformulated with an additional value property, rather than just using domain-rel. This would be,
+<pre><nowiki> <a href="www.teachmegooglemaps.com" class="sem-rel" title="http://apihut.com/taxonomies/domainClassification.rdf#maps"> </nowiki></pre>
-−
-<pre><nowiki> <body class="domain-rel" value="http://apihut.com/taxonomies/domainClassification.rdf#maps"> </nowiki></pre>
 ===sem-class===

← Older revision		Revision as of 09:21, 5 March 2009
Line 104:		Line 104:

	<pre><nowiki> <body class="domain-rel" title="http://apihut.com/taxonomies/domainClassification.rdf#mathematics		<pre><nowiki> <body class="domain-rel" title="http://apihut.com/taxonomies/domainClassification.rdf#mathematics
		+	http://apihut.com/taxonomies/domainClassification.rdf#biology"> ... </body> </nowiki></pre>
		+
		+	When using the class only style, the list of values ''after'' the name are considered to be the value. The previous markup, when made with
		+	class only style, would appear as follows.
		+
		+	<pre><nowiki> <body class="domain-rel http://apihut.com/taxonomies/domainClassification.rdf#mathematics
	http://apihut.com/taxonomies/domainClassification.rdf#biology"> ... </body> </nowiki></pre>		http://apihut.com/taxonomies/domainClassification.rdf#biology"> ... </body> </nowiki></pre>