Loading ...
Sorry, an error occurred while loading the content.

SA-REST

Expand Messages
  • Sean Kennedy
    Hi, I am trying to write up a section of my thesis on SA-REST. As far as I can see SA-REST has similar goals to hRESTS i.e. markup HTML Web API descriptions
    Message 1 of 8 , May 5, 2011
    • 0 Attachment
      Hi,
            I am trying to write up a section of my thesis on SA-REST. As far as I can see SA-REST has similar goals to hRESTS i.e. markup HTML Web API descriptions with semantic metadata. I have a few q's that I am looking for help with:

      1. Where does SA-REST fit in? The service model [1] looks very similar to the service model of hRESTS [2]. According to the diagram at the start of [2], SA-REST sits on top of hRESTS - why then does SA-REST define a similar service model?
      2. According to [2], SA-REST supports faceted search. Where are "p-lang-binding" and "data-format" [2] coming from? Why is there no mention of them in the W3C Submission ? [3].
      3. In its service model [1], there is no lifting/lowering. How is this done when using SA-REST?
      4. Are there tools such as SWEET [4] for annotating HTML with SA-REST?
      5. I am struggling to find a nice simple HTML example (not in RDFa), such as the hotel example [2].

      Thanks,
      Sean.

      [1] SA-REST service model http://www.w3.org/Submission/SA-REST/#sec_7
      [2] hRESTS: an HTML Microformat for Describing RWS http://knoesis.wright.edu/research/srl/projects/hRESTs/#restfulExample
      [3] SA-REST service model http://www.w3.org/Submission/SA-REST/
      [4] SWEET http://coconut.tie.nl:8080/dashboard/#1304592891993

    • Areeb
      Hello Sean, It has been some time since I ve looked at SA-REST and hRESTs, but I quickly viewed the links you provided and on first impressions I thought that
      Message 2 of 8 , May 5, 2011
      • 0 Attachment
        Hello Sean,

        It has been some time since I've looked at SA-REST and hRESTs, but I quickly viewed the links you provided and on first impressions I thought that SA-REST can be viewed as a vocabulary to semantically describe a RESTful Service. While hRESTs is a way to embed that vocabulary in an HTML file, however this is not entirely correct.

        There is as you pointed out an overlapping between the two and neither of them is clearly or completely defined.

        I think the overlapping is because SA-REST came slightly before hRESTs and now they are saying that SA-REST can be viewed as an extension to hRESTs that offers things like p-lang-binding and data-format which strangely enough isn't mentioned in their W3C submission, so maybe it's something they dropped or added later, I guess dropped according to dates but I'm not sure.

        About SA-RESTs lifting/lowering they mention it in a paper (older than the W3C submission) this is the paper
        SA-REST: Semantically Interoperable and Easier- to-Use Services and Mashups
        http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4376235
        and in it there is a simple example of SA-REST (I suspect an old one). (if u can't access the paper I can send the example to u)

        So it seems SA-REST is not established yet, they keep on changing it without stating how it changed.

        I hope this is helpful,

        Regards,

        Areeb

        --- In rest-discuss@yahoogroups.com, Sean Kennedy <seandkennedy@...> wrote:
        >
        > Hi,
        > I am trying to write up a section of my thesis on SA-REST. As far as I
        > can see SA-REST has similar goals to hRESTS i.e. markup HTML Web API
        > descriptions with semantic metadata. I have a few q's that I am looking for
        > help with:
        >
        > 1. Where does SA-REST fit in? The service model [1] looks very similar to the
        > service model of hRESTS [2]. According to the diagram at the start of [2],
        > SA-REST sits on top of hRESTS - why then does SA-REST define a similar service
        > model?
        >
        > 2. According to [2], SA-REST supports faceted search. Where are "p-lang-binding"
        > and "data-format" [2] coming from? Why is there no mention of them in the W3C
        > Submission ? [3].
        > 3. In its service model [1], there is no lifting/lowering. How is this done
        > when using SA-REST?
        > 4. Are there tools such as SWEET [4] for annotating HTML with SA-REST?
        > 5. I am struggling to find a nice simple HTML example (not in RDFa), such as the
        > hotel example [2].
        >
        > Thanks,
        > Sean.
        >
        > [1] SA-REST service model http://www.w3.org/Submission/SA-REST/#sec_7
        > [2] hRESTS: an HTML Microformat for Describing RWS
        > http://knoesis.wright.edu/research/srl/projects/hRESTs/#restfulExample
        > [3] SA-REST service model http://www.w3.org/Submission/SA-REST/
        > [4] SWEET http://coconut.tie.nl:8080/dashboard/#1304592891993
        >
      • Eric J. Bowman
        ... Hopefully, explaining to the REST community what this is, and what it has to do with REST? ;-) What s the overall topic of your thesis? ... We ve
        Message 3 of 8 , May 5, 2011
        • 0 Attachment
          Sean Kennedy wrote:
          >
          > I am trying to write up a section of my thesis on SA-REST.
          >

          Hopefully, explaining to the REST community what this is, and what it
          has to do with REST? ;-) What's the overall topic of your thesis?

          >
          > I have a few q's that I am looking for help with:
          >

          We've bandied-about the issue of whether or not IDLs have any place in
          REST, many times. Since I don't see the point of an IDL when using the
          hypertext constraint, I don't see the point of IDL-as-microformat,
          either. I've also never seen the point of a machine-readable service
          document as an endpoint user-agents need to consult before taking
          action -- what results is some other architectural style (where the
          semantics of the URI mappings vary based on some hash table at an
          "entry point" URI, instead of remaining RESTfully static).

          So I can't answer your questions, since I don't know how this "fits in"
          with REST, either. What hRESTS/SA-REST look like to me, is kludged-in
          tooling support to more efficiently produce the HTTP APIs most folks
          *call* REST APIs these days. Remember, I don't judge APIs by whether
          they're RESTful, only how well they're suited to their purposes, so I'm
          not scorning any project which may result in better APIs -- my *opinion*
          is that this approach may even lead some people _to_ REST's hypertext
          constraint, so it's probably a good thing, just mis-labeled.

          We've also discussed machine-readability many times; there are those
          who prefer machine-targeted data types, and those who prefer RDFa. I
          see RDFa as a superior solution to microformats, for any purpose, and
          hRESTS is another example of why -- instead of a general-purpose parsing
          model, each microformat has its own unique parsing model, usually
          defined as XSLT -- as is the case with hRESTS/SA-REST, which GRDDL-maps
          its microformat to RDF, begging the question "why not just use RDFa?"

          Interoperability is a concern; modular XHTML encompasses Xforms, which
          gives the ability to "describe" more HTTP-method-rich APIs, but those
          tokens collide with hRESTS -- which really shouldn't use class='label'
          because that collides with <label>, as well. The reason it's easier to
          create RDF vocabularies than it is to create markup languages (or even
          microformats), is the vocabulary author doesn't have to worry about if
          browsers' javascript forms-modules reserve 'label' as a keyword, etc.

          In a nutshell, I don't see how using hRESTS/SA-REST would result in the
          RESTful APIs I've done using Xforms/RDFa; although by solving what I
          who doesn't use tooling for API development considers a non-problem, I
          can see how I could've produced functionally-equivalent HTTP APIs in a
          fraction of the time. Which seems to be the problem with any effort to
          mass-produce RESTful APIs, what's lost in translation is all the design-
          for-longevity goodness which distinguishes REST APIs from HTTP APIs.

          The hRESTS/SA-REST approach intrigues me from an HTTP tinkerer
          perspective, supporting server-parsed server-configuration-on-the-fly.
          On one hand, this would philosophically violate separation of concerns;
          OTOH, long-term maintenance of Web systems based on static files may
          benefit from having fewer files to edit.

          >
          > 1. Where does SA-REST fit in? The service model [1] looks very
          > similar to the service model of hRESTS [2]. According to the diagram
          > at the start of [2], SA-REST sits on top of hRESTS - why then does
          > SA-REST define a similar service model?
          >

          Perhaps you should ask this of the authors, since they're the same?

          >
          > 2. According to [2], SA-REST supports faceted search. Where are
          > "p-lang-binding" and "data-format" [2] coming from? Why is there no
          > mention of them in the W3C Submission ? [3].
          >

          That is a good question, and if it's machine readable, then where are
          those tokens like PHP and Java defined and how is versioning accounted
          for? I understand the problem of mashing up services which use
          different formats, but I don't understand the rationale of solving this
          by making services searchable by data format (or any other "facet"),
          let alone what it has to do with REST other than attaching that name to
          new IBM products which support this feature. Seems like tight coupling
          to me, hence my confusion on calling it REST...

          Particularly when their example of a RESTful Web Service is a JSON-RPC
          endpoint.

          >
          > 3. In its service model [1], there is no lifting/lowering. How is
          > this done when using SA-REST?
          >

          What *are* lifting and lowering?

          -Eric
        • Sean Kennedy
          Hi Eric, Thanks for the time you took on that detailed response - appreciate it. My thesis is based on a mapping framework transforming XML Web Services (both
          Message 4 of 8 , May 6, 2011
          • 0 Attachment
            Hi Eric,
                 Thanks for the time you took on that detailed response - appreciate it. My thesis is based on a mapping framework transforming XML Web Services (both SOAP and POX) to RESTful HTTP format. This framework has two stages: a) a configuration stage that sets up a mapping file and b) a run-time adapter that transforms the messages based on the mapping file.
                The advantages are that this framework enables the Web architecture (POST can be replaced with GET in certain situations); the framework helps with gradual migration from SOAP/POX to RESTful HTTP WS. It has constraints of course, principally: URI limits for GET/DELETE and SOAP/POX POSTs which map logically to multiple RESTful URI's are left untouched (i.e. as a POST).
                Where the Semantic Web comes into it is in the mapping file that informs the run-time adapter. The first version had a manual setup where the user matched the XML WS operations to RESTful HTTP verbs. The second/current version uses the Semantic Web to automate this process. Currently, I use SAWSDL for the XML WS side and hRESTS/MicroWSMO on the RESTful WS side. A tool called Core Dashboard enables me to annotate both services [1]. Both sides point to the "conceptually" higher semantic ontology layer (WSMO-Lite is the standard I use for this layer).
                In my thesis I will have to cover the alternatives and originally SA-REST appeared to be that. However, the W3C submission is different to earlier publications. My information is that it is a microformat (hRESTS/MicroWSMO) versus RDFa (RDFa/SA-REST) option. So if that is the case is my logic below correct:
            1. It would appear that SA-REST is equivalent to (hRESTS + MicroWSMO). It has a service model similar to hRESTS and using the SA-REST properties (domain-rel, sem-rel and sem-class) can point to the semantic layer (as MicroWSMO does).
            2. Then using RDFa, SA-REST has the ability to be serialised from XHTML as  RDF.
            Thanks again,
            Sean.

            PS A lifting is an XSLT transformation that maps e.g. a SOAP message to the "conceptually higher" semantic layer (an RDF file); a lowering is the opposite.

            [1] Core Dashboard, http://coconut.tie.nl:8080/dashboard/#1304670463179


            From: Eric J. Bowman <eric@...>
            To: Sean Kennedy <seandkennedy@...>
            Cc: Rest Discussion Group <rest-discuss@yahoogroups.com>
            Sent: Fri, 6 May, 2011 3:57:13
            Subject: Re: [rest-discuss] SA-REST

            Sean Kennedy wrote:
            >
            > I am trying to write up a section of my thesis on SA-REST.
            >

            Hopefully, explaining to the REST community what this is, and what it
            has to do with REST?  ;-)  What's the overall topic of your thesis?

            >
            > I have a few q's that I am looking for help with:
            >

            We've bandied-about the issue of whether or not IDLs have any place in
            REST, many times.  Since I don't see the point of an IDL when using the
            hypertext constraint, I don't see the point of IDL-as-microformat,
            either.  I've also never seen the point of a machine-readable service
            document as an endpoint user-agents need to consult before taking
            action -- what results is some other architectural style (where the
            semantics of the URI mappings vary based on some hash table at an
            "entry point" URI, instead of remaining RESTfully static).

            So I can't answer your questions, since I don't know how this "fits in"
            with REST, either.  What hRESTS/SA-REST look like to me, is kludged-in
            tooling support to more efficiently produce the HTTP APIs most folks
            *call* REST APIs these days.  Remember, I don't judge APIs by whether
            they're RESTful, only how well they're suited to their purposes, so I'm
            not scorning any project which may result in better APIs -- my *opinion*
            is that this approach may even lead some people _to_ REST's hypertext
            constraint, so it's probably a good thing, just mis-labeled.

            We've also discussed machine-readability many times; there are those
            who prefer machine-targeted data types, and those who prefer RDFa.  I
            see RDFa as a superior solution to microformats, for any purpose, and
            hRESTS is another example of why -- instead of a general-purpose parsing
            model, each microformat has its own unique parsing model, usually
            defined as XSLT -- as is the case with hRESTS/SA-REST, which GRDDL-maps
            its microformat to RDF, begging the question "why not just use RDFa?"

            Interoperability is a concern; modular XHTML encompasses Xforms, which
            gives the ability to "describe" more HTTP-method-rich APIs, but those
            tokens collide with hRESTS -- which really shouldn't use class='label'
            because that collides with <label>, as well.  The reason it's easier to
            create RDF vocabularies than it is to create markup languages (or even
            microformats), is the vocabulary author doesn't have to worry about if
            browsers' javascript forms-modules reserve 'label' as a keyword, etc.

            In a nutshell, I don't see how using hRESTS/SA-REST would result in the
            RESTful APIs I've done using Xforms/RDFa; although by solving what I
            who doesn't use tooling for API development considers a non-problem, I
            can see how I could've produced functionally-equivalent HTTP APIs in a
            fraction of the time.  Which seems to be the problem with any effort to
            mass-produce RESTful APIs, what's lost in translation is all the design-
            for-longevity goodness which distinguishes REST APIs from HTTP APIs.

            The hRESTS/SA-REST approach intrigues me from an HTTP tinkerer
            perspective, supporting server-parsed server-configuration-on-the-fly.
            On one hand, this would philosophically violate separation of concerns;
            OTOH, long-term maintenance of Web systems based on static files may
            benefit from having fewer files to edit.

            >
            > 1. Where does SA-REST fit in? The service model [1] looks very
            > similar to the service model of hRESTS [2]. According to the diagram
            > at the start of  [2], SA-REST sits on top of hRESTS - why then does
            > SA-REST  define a similar service model?
            >

            Perhaps you should ask this of the authors, since they're the same?

            >
            > 2. According to [2], SA-REST supports faceted search. Where are
            > "p-lang-binding" and "data-format" [2] coming from? Why is there no
            > mention of them in the W3C Submission ? [3].
            >

            That is a good question, and if it's machine readable, then where are
            those tokens like PHP and Java defined and how is versioning accounted
            for?  I understand the problem of mashing up services which use
            different formats, but I don't understand the rationale of solving this
            by making services searchable by data format (or any other "facet"),
            let alone what it has to do with REST other than attaching that name to
            new IBM products which support this feature.  Seems like tight coupling
            to me, hence my confusion on calling it REST...

            Particularly when their example of a RESTful Web Service is a JSON-RPC
            endpoint.

            >
            > 3. In its service model [1], there is no  lifting/lowering. How is
            > this done when using SA-REST?
            >

            What *are* lifting and lowering?

            -Eric
          • Sean Kennedy
            Hi Eric, Thanks for the time you took on that detailed response - appreciate it. My thesis is based on a mapping framework transforming XML Web Services (both
            Message 5 of 8 , May 6, 2011
            • 0 Attachment
              Hi Eric,
                   Thanks for the time you took on that detailed response - appreciate it. My thesis is based on a mapping framework transforming XML Web Services (both SOAP and POX) to RESTful HTTP format. This framework has two stages: a) a configuration stage that sets up a mapping file and b) a run-time adapter that transforms the messages based on the mapping file.
                  The advantages are that this framework enables the Web architecture (POST can be replaced with GET in certain situations); the framework helps with gradual migration from SOAP/POX to RESTful HTTP WS. It has constraints of course, principally: URI limits for GET/DELETE and SOAP/POX POSTs which map logically to multiple RESTful URI's are left untouched (i.e. as a POST).
                  Where the Semantic Web comes into it is in the mapping file that informs the run-time adapter. The first version had a manual setup where the user matched the XML WS operations to RESTful HTTP verbs. The second/current version uses the Semantic Web to automate this process. Currently, I use SAWSDL for the XML WS side and hRESTS/MicroWSMO on the RESTful WS side. A tool called Core Dashboard enables me to annotate both services [1]. Both sides point to the "conceptually" higher semantic ontology layer (WSMO-Lite is the standard I use for this layer).
                  In my thesis I will have to cover the alternatives and originally SA-REST appeared to be that. However, the W3C submission is different to earlier publications. My information is that it is a microformat (hRESTS/MicroWSMO) versus RDFa (RDFa/SA-REST) option. So if that is the case is my logic below correct:
              1. It would appear that SA-REST is equivalent to (hRESTS + MicroWSMO). It has a service model similar to hRESTS and using the SA-REST properties (domain-rel, sem-rel and sem-class) can point to the semantic layer (as MicroWSMO does).
              2. Then using RDFa, SA-REST has the ability to be serialised from XHTML as  RDF.
              Thanks again,
              Sean.

              PS A lifting is an XSLT transformation that maps e.g. a SOAP message to the "conceptually higher" semantic layer (an RDF file); a lowering is the opposite.

              [1] Core Dashboard, http://coconut.tie.nl:8080/dashboard/#1304670463179


              From: Eric J. Bowman <eric@...>
              To: Sean Kennedy <seandkennedy@...>
              Cc: Rest Discussion Group <rest-discuss@yahoogroups.com>
              Sent: Fri, 6 May, 2011 3:57:13
              Subject: Re: [rest-discuss] SA-REST

              Sean Kennedy wrote:
              >
              > I am trying to write up a section of my thesis on SA-REST.
              >

              Hopefully, explaining to the REST community what this is, and what it
              has to do with REST?  ;-)  What's the overall topic of your thesis?

              >
              > I have a few q's that I am looking for help with:
              >

              We've bandied-about the issue of whether or not IDLs have any place in
              REST, many times.  Since I don't see the point of an IDL when using the
              hypertext constraint, I don't see the point of IDL-as-microformat,
              either.  I've also never seen the point of a machine-readable service
              document as an endpoint user-agents need to consult before taking
              action -- what results is some other architectural style (where the
              semantics of the URI mappings vary based on some hash table at an
              "entry point" URI, instead of remaining RESTfully static).

              So I can't answer your questions, since I don't know how this "fits in"
              with REST, either.  What hRESTS/SA-REST look like to me, is kludged-in
              tooling support to more efficiently produce the HTTP APIs most folks
              *call* REST APIs these days.  Remember, I don't judge APIs by whether
              they're RESTful, only how well they're suited to their purposes, so I'm
              not scorning any project which may result in better APIs -- my *opinion*
              is that this approach may even lead some people _to_ REST's hypertext
              constraint, so it's probably a good thing, just mis-labeled.

              We've also discussed machine-readability many times; there are those
              who prefer machine-targeted data types, and those who prefer RDFa.  I
              see RDFa as a superior solution to microformats, for any purpose, and
              hRESTS is another example of why -- instead of a general-purpose parsing
              model, each microformat has its own unique parsing model, usually
              defined as XSLT -- as is the case with hRESTS/SA-REST, which GRDDL-maps
              its microformat to RDF, begging the question "why not just use RDFa?"

              Interoperability is a concern; modular XHTML encompasses Xforms, which
              gives the ability to "describe" more HTTP-method-rich APIs, but those
              tokens collide with hRESTS -- which really shouldn't use class='label'
              because that collides with <label>, as well.  The reason it's easier to
              create RDF vocabularies than it is to create markup languages (or even
              microformats), is the vocabulary author doesn't have to worry about if
              browsers' javascript forms-modules reserve 'label' as a keyword, etc.

              In a nutshell, I don't see how using hRESTS/SA-REST would result in the
              RESTful APIs I've done using Xforms/RDFa; although by solving what I
              who doesn't use tooling for API development considers a non-problem, I
              can see how I could've produced functionally-equivalent HTTP APIs in a
              fraction of the time.  Which seems to be the problem with any effort to
              mass-produce RESTful APIs, what's lost in translation is all the design-
              for-longevity goodness which distinguishes REST APIs from HTTP APIs.

              The hRESTS/SA-REST approach intrigues me from an HTTP tinkerer
              perspective, supporting server-parsed server-configuration-on-the-fly.
              On one hand, this would philosophically violate separation of concerns;
              OTOH, long-term maintenance of Web systems based on static files may
              benefit from having fewer files to edit.

              >
              > 1. Where does SA-REST fit in? The service model [1] looks very
              > similar to the service model of hRESTS [2]. According to the diagram
              > at the start of  [2], SA-REST sits on top of hRESTS - why then does
              > SA-REST  define a similar service model?
              >

              Perhaps you should ask this of the authors, since they're the same?

              >
              > 2. According to [2], SA-REST supports faceted search. Where are
              > "p-lang-binding" and "data-format" [2] coming from? Why is there no
              > mention of them in the W3C Submission ? [3].
              >

              That is a good question, and if it's machine readable, then where are
              those tokens like PHP and Java defined and how is versioning accounted
              for?  I understand the problem of mashing up services which use
              different formats, but I don't understand the rationale of solving this
              by making services searchable by data format (or any other "facet"),
              let alone what it has to do with REST other than attaching that name to
              new IBM products which support this feature.  Seems like tight coupling
              to me, hence my confusion on calling it REST...

              Particularly when their example of a RESTful Web Service is a JSON-RPC
              endpoint.

              >
              > 3. In its service model [1], there is no  lifting/lowering. How is
              > this done when using SA-REST?
              >

              What *are* lifting and lowering?

              -Eric
            • Sean Kennedy
              Hi Eric, Thanks for the time you took on that detailed response - appreciate it. My thesis is based on a mapping framework transforming XML Web Services (both
              Message 6 of 8 , May 6, 2011
              • 0 Attachment
                Hi Eric,
                     Thanks for the time you took on that detailed response - appreciate it. My thesis is based on a mapping framework transforming XML Web Services (both SOAP and POX) to RESTful HTTP format. This framework has two stages: a) a configuration stage that sets up a mapping file and b) a run-time adapter that transforms the messages based on the mapping file.
                    The advantages are that this framework enables the Web architecture (POST can be replaced with GET in certain situations); the framework helps with gradual migration from SOAP/POX to RESTful HTTP WS. It has constraints of course, principally: URI limits for GET/DELETE and SOAP/POX POSTs which map logically to multiple RESTful URI's are left untouched (i.e. as a POST).
                    Where the Semantic Web comes into it is in the mapping file that informs the run-time adapter. The first version had a manual setup where the user matched the XML WS operations to RESTful HTTP verbs. The second/current version uses the Semantic Web to automate this process. Currently, I use SAWSDL for the XML WS side and hRESTS/MicroWSMO on the RESTful WS side. A tool called Core Dashboard enables me to annotate both services [1]. Both sides point to the "conceptually" higher semantic ontology layer (WSMO-Lite is the standard I use for this layer).
                    In my thesis I will have to cover the alternatives and originally SA-REST appeared to be that. However, the W3C submission is different to earlier publications. My information is that it is a microformat (hRESTS/MicroWSMO) versus RDFa (RDFa/SA-REST) option. So if that is the case is my logic below correct:
                1. It would appear that SA-REST is equivalent to (hRESTS + MicroWSMO). It has a service model similar to hRESTS and using the SA-REST properties (domain-rel, sem-rel and sem-class) can point to the semantic layer (as MicroWSMO does).
                2. Then using RDFa, SA-REST has the ability to be serialised from XHTML as  RDF.
                Thanks again,
                Sean.

                PS A lifting is an XSLT transformation that maps e.g. a SOAP message to the "conceptually higher" semantic layer (an RDF file); a lowering is the opposite.

                [1] Core Dashboard, http://coconut.tie.nl:8080/dashboard/#1304670463179


                From: Eric J. Bowman <eric@...>
                To: Sean Kennedy <seandkennedy@...>
                Cc: Rest Discussion Group <rest-discuss@yahoogroups.com>
                Sent: Fri, 6 May, 2011 3:57:13
                Subject: Re: [rest-discuss] SA-REST

                Sean Kennedy wrote:
                >
                > I am trying to write up a section of my thesis on SA-REST.
                >

                Hopefully, explaining to the REST community what this is, and what it
                has to do with REST?  ;-)  What's the overall topic of your thesis?

                >
                > I have a few q's that I am looking for help with:
                >

                We've bandied-about the issue of whether or not IDLs have any place in
                REST, many times.  Since I don't see the point of an IDL when using the
                hypertext constraint, I don't see the point of IDL-as-microformat,
                either.  I've also never seen the point of a machine-readable service
                document as an endpoint user-agents need to consult before taking
                action -- what results is some other architectural style (where the
                semantics of the URI mappings vary based on some hash table at an
                "entry point" URI, instead of remaining RESTfully static).

                So I can't answer your questions, since I don't know how this "fits in"
                with REST, either.  What hRESTS/SA-REST look like to me, is kludged-in
                tooling support to more efficiently produce the HTTP APIs most folks
                *call* REST APIs these days.  Remember, I don't judge APIs by whether
                they're RESTful, only how well they're suited to their purposes, so I'm
                not scorning any project which may result in better APIs -- my *opinion*
                is that this approach may even lead some people _to_ REST's hypertext
                constraint, so it's probably a good thing, just mis-labeled.

                We've also discussed machine-readability many times; there are those
                who prefer machine-targeted data types, and those who prefer RDFa.  I
                see RDFa as a superior solution to microformats, for any purpose, and
                hRESTS is another example of why -- instead of a general-purpose parsing
                model, each microformat has its own unique parsing model, usually
                defined as XSLT -- as is the case with hRESTS/SA-REST, which GRDDL-maps
                its microformat to RDF, begging the question "why not just use RDFa?"

                Interoperability is a concern; modular XHTML encompasses Xforms, which
                gives the ability to "describe" more HTTP-method-rich APIs, but those
                tokens collide with hRESTS -- which really shouldn't use class='label'
                because that collides with <label>, as well.  The reason it's easier to
                create RDF vocabularies than it is to create markup languages (or even
                microformats), is the vocabulary author doesn't have to worry about if
                browsers' javascript forms-modules reserve 'label' as a keyword, etc.

                In a nutshell, I don't see how using hRESTS/SA-REST would result in the
                RESTful APIs I've done using Xforms/RDFa; although by solving what I
                who doesn't use tooling for API development considers a non-problem, I
                can see how I could've produced functionally-equivalent HTTP APIs in a
                fraction of the time.  Which seems to be the problem with any effort to
                mass-produce RESTful APIs, what's lost in translation is all the design-
                for-longevity goodness which distinguishes REST APIs from HTTP APIs.

                The hRESTS/SA-REST approach intrigues me from an HTTP tinkerer
                perspective, supporting server-parsed server-configuration-on-the-fly.
                On one hand, this would philosophically violate separation of concerns;
                OTOH, long-term maintenance of Web systems based on static files may
                benefit from having fewer files to edit.

                >
                > 1. Where does SA-REST fit in? The service model [1] looks very
                > similar to the service model of hRESTS [2]. According to the diagram
                > at the start of  [2], SA-REST sits on top of hRESTS - why then does
                > SA-REST  define a similar service model?
                >

                Perhaps you should ask this of the authors, since they're the same?

                >
                > 2. According to [2], SA-REST supports faceted search. Where are
                > "p-lang-binding" and "data-format" [2] coming from? Why is there no
                > mention of them in the W3C Submission ? [3].
                >

                That is a good question, and if it's machine readable, then where are
                those tokens like PHP and Java defined and how is versioning accounted
                for?  I understand the problem of mashing up services which use
                different formats, but I don't understand the rationale of solving this
                by making services searchable by data format (or any other "facet"),
                let alone what it has to do with REST other than attaching that name to
                new IBM products which support this feature.  Seems like tight coupling
                to me, hence my confusion on calling it REST...

                Particularly when their example of a RESTful Web Service is a JSON-RPC
                endpoint.

                >
                > 3. In its service model [1], there is no  lifting/lowering. How is
                > this done when using SA-REST?
                >

                What *are* lifting and lowering?

                -Eric
              • Saravanakumaar Jeyabalan
                Sean, Hope you took a look at Hypermedia and Model-Driven Development presented in WS-REST 2011.  The links for the paper and slides are here:
                Message 7 of 8 , May 12, 2011
                • 0 Attachment
                  Sean,
                   
                  Hope you took a look at Hypermedia and Model-Driven Development presented in WS-REST 2011.  The links for the paper and slides are here: http://ws-rest.org/2011/proc/a2-liskin.pdf and http://ws-rest.org/2011/proc/s2-liskin.pdf
                   
                  I too am working on creating a similar tool.  I'm thinking on how to go about implementing the client framework which should work on any SOAP to RESTful service.  In case you have come across any design for the same please share.  Thanks!
                   
                  Best regards,
                  Saravan.


                  From: Sean Kennedy <seandkennedy@...>
                  To: Eric J. Bowman <eric@...>
                  Cc: Rest Discussion Group <rest-discuss@yahoogroups.com>
                  Sent: Fri, 6 May, 2011 4:31:38 PM
                  Subject: Re: [rest-discuss] SA-REST

                   

                  Hi Eric,
                       Thanks for the time you took on that detailed response - appreciate it. My thesis is based on a mapping framework transforming XML Web Services (both SOAP and POX) to RESTful HTTP format. This framework has two stages: a) a configuration stage that sets up a mapping file and b) a run-time adapter that transforms the messages based on the mapping file.
                      The advantages are that this framework enables the Web architecture (POST can be replaced with GET in certain situations); the framework helps with gradual migration from SOAP/POX to RESTful HTTP WS. It has constraints of course, principally: URI limits for GET/DELETE and SOAP/POX POSTs which map logically to multiple RESTful URI's are left untouched (i.e. as a POST).
                      Where the Semantic Web comes into it is in the mapping file that informs the run-time adapter. The first version had a manual setup where the user matched the XML WS operations to RESTful HTTP verbs. The second/current version uses the Semantic Web to automate this process. Currently, I use SAWSDL for the XML WS side and hRESTS/MicroWSMO on the RESTful WS side. A tool called Core Dashboard enables me to annotate both services [1]. Both sides point to the "conceptually" higher semantic ontology layer (WSMO-Lite is the standard I use for this layer).
                      In my thesis I will have to cover the alternatives and originally SA-REST appeared to be that. However, the W3C submission is different to earlier publications. My information is that it is a microformat (hRESTS/MicroWSMO) versus RDFa (RDFa/SA-REST) option. So if that is the case is my logic below correct:
                  1. It would appear that SA-REST is equivalent to (hRESTS + MicroWSMO). It has a service model similar to hRESTS and using the SA-REST properties (domain-rel, sem-rel and sem-class) can point to the semantic layer (as MicroWSMO does).
                  2. Then using RDFa, SA-REST has the ability to be serialised from XHTML as  RDF.
                  Thanks again,
                  Sean.

                  PS A lifting is an XSLT transformation that maps e.g. a SOAP message to the "conceptually higher" semantic layer (an RDF file); a lowering is the opposite.

                  [1] Core Dashboard, http://coconut.tie.nl:8080/dashboard/#1304670463179


                  From: Eric J. Bowman <eric@...>
                  To: Sean Kennedy <seandkennedy@...>
                  Cc: Rest Discussion Group <rest-discuss@yahoogroups.com>
                  Sent: Fri, 6 May, 2011 3:57:13
                  Subject: Re: [rest-discuss] SA-REST

                  Sean Kennedy wrote:
                  >
                  > I am trying to write up a section of my thesis on SA-REST.
                  >

                  Hopefully, explaining to the REST community what this is, and what it
                  has to do with REST?  ;-)  What's the overall topic of your thesis?

                  >
                  > I have a few q's that I am looking for help with:
                  >

                  We've bandied-about the issue of whether or not IDLs have any place in
                  REST, many times.  Since I don't see the point of an IDL when using the
                  hypertext constraint, I don't see the point of IDL-as-microformat,
                  either.  I've also never seen the point of a machine-readable service
                  document as an endpoint user-agents need to consult before taking
                  action -- what results is some other architectural style (where the
                  semantics of the URI mappings vary based on some hash table at an
                  "entry point" URI, instead of remaining RESTfully static).

                  So I can't answer your questions, since I don't know how this "fits in"
                  with REST, either.  What hRESTS/SA-REST look like to me, is kludged-in
                  tooling support to more efficiently produce the HTTP APIs most folks
                  *call* REST APIs these days.  Remember, I don't judge APIs by whether
                  they're RESTful, only how well they're suited to their purposes, so I'm
                  not scorning any project which may result in better APIs -- my *opinion*
                  is that this approach may even lead some people _to_ REST's hypertext
                  constraint, so it's probably a good thing, just mis-labeled.

                  We've also discussed machine-readability many times; there are those
                  who prefer machine-targeted data types, and those who prefer RDFa.  I
                  see RDFa as a superior solution to microformats, for any purpose, and
                  hRESTS is another example of why -- instead of a general-purpose parsing
                  model, each microformat has its own unique parsing model, usually
                  defined as XSLT -- as is the case with hRESTS/SA-REST, which GRDDL-maps
                  its microformat to RDF, begging the question "why not just use RDFa?"

                  Interoperability is a concern; modular XHTML encompasses Xforms, which
                  gives the ability to "describe" more HTTP-method-rich APIs, but those
                  tokens collide with hRESTS -- which really shouldn't use class='label'
                  because that collides with <label>, as well.  The reason it's easier to
                  create RDF vocabularies than it is to create markup languages (or even
                  microformats), is the vocabulary author doesn't have to worry about if
                  browsers' javascript forms-modules reserve 'label' as a keyword, etc.

                  In a nutshell, I don't see how using hRESTS/SA-REST would result in the
                  RESTful APIs I've done using Xforms/RDFa; although by solving what I
                  who doesn't use tooling for API development considers a non-problem, I
                  can see how I could've produced functionally-equivalent HTTP APIs in a
                  fraction of the time.  Which seems to be the problem with any effort to
                  mass-produce RESTful APIs, what's lost in translation is all the design-
                  for-longevity goodness which distinguishes REST APIs from HTTP APIs.

                  The hRESTS/SA-REST approach intrigues me from an HTTP tinkerer
                  perspective, supporting server-parsed server-configuration-on-the-fly.
                  On one hand, this would philosophically violate separation of concerns;
                  OTOH, long-term maintenance of Web systems based on static files may
                  benefit from having fewer files to edit.

                  >
                  > 1. Where does SA-REST fit in? The service model [1] looks very
                  > similar to the service model of hRESTS [2]. According to the diagram
                  > at the start of  [2], SA-REST sits on top of hRESTS - why then does
                  > SA-REST  define a similar service model?
                  >

                  Perhaps you should ask this of the authors, since they're the same?

                  >
                  > 2. According to [2], SA-REST supports faceted search. Where are
                  > "p-lang-binding" and "data-format" [2] coming from? Why is there no
                  > mention of them in the W3C Submission ? [3].
                  >

                  That is a good question, and if it's machine readable, then where are
                  those tokens like PHP and Java defined and how is versioning accounted
                  for?  I understand the problem of mashing up services which use
                  different formats, but I don't understand the rationale of solving this
                  by making services searchable by data format (or any other "facet"),
                  let alone what it has to do with REST other than attaching that name to
                  new IBM products which support this feature.  Seems like tight coupling
                  to me, hence my confusion on calling it REST...

                  Particularly when their example of a RESTful Web Service is a JSON-RPC
                  endpoint.

                  >
                  > 3. In its service model [1], there is no  lifting/lowering. How is
                  > this done when using SA-REST?
                  >

                  What *are* lifting and lowering?

                  -Eric
                • Sean Kennedy
                  Hi Saravan, Thanks for that. Some work that may be of interest to you is http://dev.aol.com/rest_and_soap_sharing (thanks to Stefan Tilkov for that link).
                  Message 8 of 8 , May 17, 2011
                  • 0 Attachment
                    Hi Saravan,
                          Thanks for that. Some work that may be of interest to you is http://dev.aol.com/rest_and_soap_sharing (thanks to Stefan Tilkov for that link).

                    Regards,
                    Sean.


                    From: Saravanakumaar Jeyabalan <jsarava@...>
                    To: Sean Kennedy <seandkennedy@...>; Eric J. Bowman <eric@...>
                    Cc: Rest Discussion Group <rest-discuss@yahoogroups.com>
                    Sent: Fri, 13 May, 2011 2:08:58
                    Subject: Re: [rest-discuss] SA-REST

                     

                    Sean,
                     
                    Hope you took a look at Hypermedia and Model-Driven Development presented in WS-REST 2011.  The links for the paper and slides are here: http://ws-rest.org/2011/proc/a2-liskin.pdf and http://ws-rest.org/2011/proc/s2-liskin.pdf
                     
                    I too am working on creating a similar tool.  I'm thinking on how to go about implementing the client framework which should work on any SOAP to RESTful service.  In case you have come across any design for the same please share.  Thanks!
                     
                    Best regards,
                    Saravan.


                    From: Sean Kennedy <seandkennedy@...>
                    To: Eric J. Bowman <eric@...>
                    Cc: Rest Discussion Group <rest-discuss@yahoogroups.com>
                    Sent: Fri, 6 May, 2011 4:31:38 PM
                    Subject: Re: [rest-discuss] SA-REST

                     

                    Hi Eric,
                         Thanks for the time you took on that detailed response - appreciate it. My thesis is based on a mapping framework transforming XML Web Services (both SOAP and POX) to RESTful HTTP format. This framework has two stages: a) a configuration stage that sets up a mapping file and b) a run-time adapter that transforms the messages based on the mapping file.
                        The advantages are that this framework enables the Web architecture (POST can be replaced with GET in certain situations); the framework helps with gradual migration from SOAP/POX to RESTful HTTP WS. It has constraints of course, principally: URI limits for GET/DELETE and SOAP/POX POSTs which map logically to multiple RESTful URI's are left untouched (i.e. as a POST).
                        Where the Semantic Web comes into it is in the mapping file that informs the run-time adapter. The first version had a manual setup where the user matched the XML WS operations to RESTful HTTP verbs. The second/current version uses the Semantic Web to automate this process. Currently, I use SAWSDL for the XML WS side and hRESTS/MicroWSMO on the RESTful WS side. A tool called Core Dashboard enables me to annotate both services [1]. Both sides point to the "conceptually" higher semantic ontology layer (WSMO-Lite is the standard I use for this layer).
                        In my thesis I will have to cover the alternatives and originally SA-REST appeared to be that. However, the W3C submission is different to earlier publications. My information is that it is a microformat (hRESTS/MicroWSMO) versus RDFa (RDFa/SA-REST) option. So if that is the case is my logic below correct:
                    1. It would appear that SA-REST is equivalent to (hRESTS + MicroWSMO). It has a service model similar to hRESTS and using the SA-REST properties (domain-rel, sem-rel and sem-class) can point to the semantic layer (as MicroWSMO does).
                    2. Then using RDFa, SA-REST has the ability to be serialised from XHTML as  RDF.
                    Thanks again,
                    Sean.

                    PS A lifting is an XSLT transformation that maps e.g. a SOAP message to the "conceptually higher" semantic layer (an RDF file); a lowering is the opposite.

                    [1] Core Dashboard, http://coconut.tie.nl:8080/dashboard/#1304670463179


                    From: Eric J. Bowman <eric@...>
                    To: Sean Kennedy <seandkennedy@...>
                    Cc: Rest Discussion Group <rest-discuss@yahoogroups.com>
                    Sent: Fri, 6 May, 2011 3:57:13
                    Subject: Re: [rest-discuss] SA-REST

                    Sean Kennedy wrote:
                    >
                    > I am trying to write up a section of my thesis on SA-REST.
                    >

                    Hopefully, explaining to the REST community what this is, and what it
                    has to do with REST?  ;-)  What's the overall topic of your thesis?

                    >
                    > I have a few q's that I am looking for help with:
                    >

                    We've bandied-about the issue of whether or not IDLs have any place in
                    REST, many times.  Since I don't see the point of an IDL when using the
                    hypertext constraint, I don't see the point of IDL-as-microformat,
                    either.  I've also never seen the point of a machine-readable service
                    document as an endpoint user-agents need to consult before taking
                    action -- what results is some other architectural style (where the
                    semantics of the URI mappings vary based on some hash table at an
                    "entry point" URI, instead of remaining RESTfully static).

                    So I can't answer your questions, since I don't know how this "fits in"
                    with REST, either.  What hRESTS/SA-REST look like to me, is kludged-in
                    tooling support to more efficiently produce the HTTP APIs most folks
                    *call* REST APIs these days.  Remember, I don't judge APIs by whether
                    they're RESTful, only how well they're suited to their purposes, so I'm
                    not scorning any project which may result in better APIs -- my *opinion*
                    is that this approach may even lead some people _to_ REST's hypertext
                    constraint, so it's probably a good thing, just mis-labeled.

                    We've also discussed machine-readability many times; there are those
                    who prefer machine-targeted data types, and those who prefer RDFa.  I
                    see RDFa as a superior solution to microformats, for any purpose, and
                    hRESTS is another example of why -- instead of a general-purpose parsing
                    model, each microformat has its own unique parsing model, usually
                    defined as XSLT -- as is the case with hRESTS/SA-REST, which GRDDL-maps
                    its microformat to RDF, begging the question "why not just use RDFa?"

                    Interoperability is a concern; modular XHTML encompasses Xforms, which
                    gives the ability to "describe" more HTTP-method-rich APIs, but those
                    tokens collide with hRESTS -- which really shouldn't use class='label'
                    because that collides with <label>, as well.  The reason it's easier to
                    create RDF vocabularies than it is to create markup languages (or even
                    microformats), is the vocabulary author doesn't have to worry about if
                    browsers' javascript forms-modules reserve 'label' as a keyword, etc.

                    In a nutshell, I don't see how using hRESTS/SA-REST would result in the
                    RESTful APIs I've done using Xforms/RDFa; although by solving what I
                    who doesn't use tooling for API development considers a non-problem, I
                    can see how I could've produced functionally-equivalent HTTP APIs in a
                    fraction of the time.  Which seems to be the problem with any effort to
                    mass-produce RESTful APIs, what's lost in translation is all the design-
                    for-longevity goodness which distinguishes REST APIs from HTTP APIs.

                    The hRESTS/SA-REST approach intrigues me from an HTTP tinkerer
                    perspective, supporting server-parsed server-configuration-on-the-fly.
                    On one hand, this would philosophically violate separation of concerns;
                    OTOH, long-term maintenance of Web systems based on static files may
                    benefit from having fewer files to edit.

                    >
                    > 1. Where does SA-REST fit in? The service model [1] looks very
                    > similar to the service model of hRESTS [2]. According to the diagram
                    > at the start of  [2], SA-REST sits on top of hRESTS - why then does
                    > SA-REST  define a similar service model?
                    >

                    Perhaps you should ask this of the authors, since they're the same?

                    >
                    > 2. According to [2], SA-REST supports faceted search. Where are
                    > "p-lang-binding" and "data-format" [2] coming from? Why is there no
                    > mention of them in the W3C Submission ? [3].
                    >

                    That is a good question, and if it's machine readable, then where are
                    those tokens like PHP and Java defined and how is versioning accounted
                    for?  I understand the problem of mashing up services which use
                    different formats, but I don't understand the rationale of solving this
                    by making services searchable by data format (or any other "facet"),
                    let alone what it has to do with REST other than attaching that name to
                    new IBM products which support this feature.  Seems like tight coupling
                    to me, hence my confusion on calling it REST...

                    Particularly when their example of a RESTful Web Service is a JSON-RPC
                    endpoint.

                    >
                    > 3. In its service model [1], there is no  lifting/lowering. How is
                    > this done when using SA-REST?
                    >

                    What *are* lifting and lowering?

                    -Eric
                  Your message has been successfully submitted and would be delivered to recipients shortly.