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

REST and SKOS

Expand Messages
  • Alexander Johannesen
    Hi all, Just a quickie; Anyone done any work with delivering RESTful SKOS resources? I m tossing up embedding SKOS in ATOM with extensions or roll my own, both
    Message 1 of 12 , Nov 30, 2010
    • 0 Attachment
      Hi all,

      Just a quickie;

      Anyone done any work with delivering RESTful SKOS resources? I'm
      tossing up embedding SKOS in ATOM with extensions or roll my own, both
      for requests and responses. Any thoughts by people in the know?


      Kind regards,

      Alex
      --
       Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
      --- http://shelter.nu/blog/ ----------------------------------------------
      ------------------ http://www.google.com/profiles/alexander.johannesen ---
    • Eric J. Bowman
      ... This seems orthogonal to REST, kinda like choosing between HTML and XHTML -- implementation details. I ve only seen SKOS mentioned here once before:
      Message 2 of 12 , Dec 1, 2010
      • 0 Attachment
        Alexander Johannesen wrote:
        >
        > Anyone done any work with delivering RESTful SKOS resources? I'm
        > tossing up embedding SKOS in ATOM with extensions or roll my own, both
        > for requests and responses. Any thoughts by people in the know?
        >

        This seems orthogonal to REST, kinda like choosing between HTML and
        XHTML -- implementation details. I've only seen SKOS mentioned here
        once before:

        http://tech.groups.yahoo.com/group/rest-discuss/message/16404

        Maybe you can ask Brian?

        -Eric
      • Alexander Johannesen
        Hi, First, thanks to Alistair, I ll respond better later. Just a quick note ; ... Hmm, ok. For me this dips into the deeper realm of making a REST
        Message 3 of 12 , Dec 1, 2010
        • 0 Attachment
          Hi,

          First, thanks to Alistair, I'll respond better later. Just a quick note ;

          On Thu, Dec 2, 2010 at 7:32 AM, Eric J. Bowman <eric@...> wrote:
          > This seems orthogonal to REST, kinda like choosing between HTML and
          > XHTML -- implementation details.

          Hmm, ok. For me this dips into the deeper realm of making a REST
          representation of a larger model; how do we represent best a model
          through REST resources? I'm a HATEOAS believer, but how to break up
          the SKOS meta model to bring a more concrete model through hyperlinks?
          I don't want to pass a format around; I want to pass a model around,
          and in doing so, are there formats I should prefer over others? (A
          preamble here is that I'm trying to avoid as best I can triplets and
          its ilk, not that it matters much)

          Of course this isn't limited to SKOS alone, so my question is a bit
          more open in that I'm looking for experiences in dealing with the meta
          model and data model (probably false) dichotomy. People who's done any
          serious ontology work and make it into a RESTful system should have a
          few good suggestions.


          Kind regards,

          Alex

          --
           Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
          --- http://shelter.nu/blog/ ----------------------------------------------
          ------------------ http://www.google.com/profiles/alexander.johannesen ---
        • mike amundsen
          ... HTTP (and REST) is about passing around varying public representations (via negotiated media-types) of private data|models, not the models
          Message 4 of 12 , Dec 1, 2010
          • 0 Attachment
            <snip>
            > I don't want to pass a format around; I want to pass a model around,
            </snip>
            HTTP (and REST) is about passing around varying public representations
            (via negotiated media-types) of private data|models, not the models
            (or resources, or tables, or classes, etc.) themselves.

            Maybe some other "representation-less" app-level protocol is what you
            want? XMPP?

            mca
            http://amundsen.com/blog/
            http://twitter.com@mamund
            http://mamund.com/foaf.rdf#me


            #RESTFest 2010
            http://rest-fest.googlecode.com




            On Wed, Dec 1, 2010 at 15:54, Alexander Johannesen
            <alexander.johannesen@...> wrote:
            > Hi,
            >
            > First, thanks to Alistair, I'll respond better later. Just a quick note ;
            >
            > On Thu, Dec 2, 2010 at 7:32 AM, Eric J. Bowman <eric@...> wrote:
            >> This seems orthogonal to REST, kinda like choosing between HTML and
            >> XHTML -- implementation details.
            >
            > Hmm, ok. For me this dips into the deeper realm of making a REST
            > representation of a larger model; how do we represent best a model
            > through REST resources? I'm a HATEOAS believer, but how to break up
            > the SKOS meta model to bring a more concrete model through hyperlinks?
            c
            > and in doing so, are there formats I should prefer over others? (A
            > preamble here is that I'm trying to avoid as best I can triplets and
            > its ilk, not that it matters much)
            >
            > Of course this isn't limited to SKOS alone, so my question is a bit
            > more open in that I'm looking for experiences in dealing with the meta
            > model and data model (probably false) dichotomy. People who's done any
            > serious ontology work and make it into a RESTful system should have a
            > few good suggestions.
            >
            >
            > Kind regards,
            >
            > Alex
            >
            > --
            >  Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
            > --- http://shelter.nu/blog/ ----------------------------------------------
            > ------------------ http://www.google.com/profiles/alexander.johannesen ---
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
          • Alexander Johannesen
            ... no, no, no. :) A model has a host of entities, relationships included, and they all can have representations. Some times they are bundled up, other times
            Message 5 of 12 , Dec 1, 2010
            • 0 Attachment
              On Thu, Dec 2, 2010 at 8:09 AM, mike amundsen <mamund@...> wrote:
              > HTTP (and REST) is about passing around varying public representations
              > (via negotiated media-types) of private data|models, not the models
              > (or resources, or tables, or classes, etc.) themselves.
              >
              > Maybe some other "representation-less" app-level protocol is what you
              > want? XMPP?

              no, no, no. :)

              A model has a host of entities, relationships included, and they all
              can have representations. Some times they are bundled up, other times
              they have their very own resource. It's about finding a meaningful /
              useful balance between it all I'm after. I can dump a complete model
              in a Topic Maps format (XTM/JTM) at one resource, a TM fragment at
              another, but still have a full RESTful API into the innards using
              other representations, all the way down to individual occurrences or
              properties inside the data model (where I'm using SKOS as a heavy
              hitter ontology).

              So, balance. And being useful. Just fishing for experience.


              Kind regards,

              Alex
              --
               Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
              --- http://shelter.nu/blog/ ----------------------------------------------
              ------------------ http://www.google.com/profiles/alexander.johannesen ---
            • mike amundsen
              OK. mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me #RESTFest 2010 http://rest-fest.googlecode.com On Wed, Dec 1, 2010 at
              Message 6 of 12 , Dec 1, 2010
              • 0 Attachment
                OK.

                mca
                http://amundsen.com/blog/
                http://twitter.com@mamund
                http://mamund.com/foaf.rdf#me


                #RESTFest 2010
                http://rest-fest.googlecode.com




                On Wed, Dec 1, 2010 at 16:15, Alexander Johannesen
                <alexander.johannesen@...> wrote:
                > On Thu, Dec 2, 2010 at 8:09 AM, mike amundsen <mamund@...> wrote:
                >> HTTP (and REST) is about passing around varying public representations
                >> (via negotiated media-types) of private data|models, not the models
                >> (or resources, or tables, or classes, etc.) themselves.
                >>
                >> Maybe some other "representation-less" app-level protocol is what you
                >> want? XMPP?
                >
                > no, no, no. :)
                >
                > A model has a host of entities, relationships included, and they all
                > can have representations. Some times they are bundled up, other times
                > they have their very own resource. It's about finding a meaningful /
                > useful balance between it all I'm after. I can dump a complete model
                > in a Topic Maps format (XTM/JTM) at one resource, a TM fragment at
                > another, but still have a full RESTful API into the innards using
                > other representations, all the way down to individual occurrences or
                > properties inside the data model (where I'm using SKOS as a heavy
                > hitter ontology).
                >
                > So, balance. And being useful. Just fishing for experience.
                >
                >
                > Kind regards,
                >
                > Alex
                > --
                >  Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
                > --- http://shelter.nu/blog/ ----------------------------------------------
                > ------------------ http://www.google.com/profiles/alexander.johannesen ---
                >
              • Alexander Johannesen
                ... Excellent observation. Luckily I m a Topic Maps guy, and we don t have this silly problem. :) But this, too, cuts a bit into some of the stuff I m trying
                Message 7 of 12 , Dec 1, 2010
                • 0 Attachment
                  On Thu, Dec 2, 2010 at 9:15 AM, Dan Brickley <danbri@...> wrote:
                  > One boring detail is the question of what the URI for a SKOS concept
                  > should be; whether it needs to be named with a #blahblah or not.
                  >
                  > This is roughly the topic known on the TAG mailing list as
                  > http-range-14 and I shudder at the thought of revisiting it again...

                  Excellent observation. Luckily I'm a Topic Maps guy, and we don't have
                  this silly problem. :) But this, too, cuts a bit into some of the
                  stuff I'm trying to work out, say different resources for identifiers,
                  locators and identity indicators, and so on, or how to deal with
                  various degrees of identification as hyperlinks, how to best represent
                  identifiers based on content-type, and on and on. I realize it's
                  becoming a bit too specific (even though I personally believe that the
                  concept of proper persistent identification management is paramount to
                  all future software systems), so I'll just leave it at that.


                  Regards,

                  Alex
                  --
                   Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
                  --- http://shelter.nu/blog/ ----------------------------------------------
                  ------------------ http://www.google.com/profiles/alexander.johannesen ---
                • Jan Algermissen
                  Alexander, ... Note that simply stating does not provide the ability to point to the image
                  Message 8 of 12 , Dec 1, 2010
                  • 0 Attachment
                    Alexander,

                    On Dec 1, 2010, at 11:22 PM, Alexander Johannesen wrote:

                    > Luckily I'm a Topic Maps guy, and we don't have
                    > this silly problem. :)

                    Note that simply stating <subjectIndicatorRef xlink:href="http://images/image-of-jim.jpg"> does not provide the ability to point to the image representation you receive upon a GET.

                    IOW, a URI by definition never points to the representation. It always points to the resource (the membership function) that maps to a set of representations or URIs over time.

                    The indirection is a feature of URIs *per design*.

                    Jan
                  • Alexander Johannesen
                    ... Um, no, of course not, that s not in the realm of identity management, so I seriously don t understand your use of an image for a subject indicator? ...
                    Message 9 of 12 , Dec 1, 2010
                    • 0 Attachment
                      On Thu, Dec 2, 2010 at 9:51 AM, Jan Algermissen <algermissen1971@...> wrote:
                      > Note that simply stating <subjectIndicatorRef xlink:href="http://images/image-of-jim.jpg">
                      > does not provide the ability to point to the image representation you receive upon a GET.

                      Um, no, of course not, that's not in the realm of identity management,
                      so I seriously don't understand your use of an image for a subject
                      indicator?

                      > IOW, a URI by definition never points to the representation. It always points to
                      > the resource (the membership function) that maps to a set of representations or URIs over time.

                      The concept here is inference about representation before resolving
                      the URI to find out what it represents. In RDF it happens after
                      resolving it, in Topic maps in terms of subject identification it
                      happens before.


                      Kind regards,

                      Alex
                      --
                       Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
                      --- http://shelter.nu/blog/ ----------------------------------------------
                      ------------------ http://www.google.com/profiles/alexander.johannesen ---
                    • Eric J. Bowman
                      ... Seems inevitable. Don t get me wrong, I agree with the finding, due to my understanding of the architecture. The problem is, if we were to poll Web
                      Message 10 of 12 , Dec 1, 2010
                      • 0 Attachment
                        Dan Brickley wrote:
                        >
                        > This is roughly the topic known on the TAG mailing list as
                        > http-range-14 and I shudder at the thought of revisiting it again...
                        >

                        Seems inevitable. Don't get me wrong, I agree with the finding, due to
                        my understanding of the architecture. The problem is, if we were to
                        poll Web developers we'd find that an overwhelming majority think it's
                        wrong -- due to a lack of understanding of Web architecture.

                        http://cacm.acm.org/magazines/2008/7/5366-web-science/fulltext

                        TBL raises an interesting point -- Web Design is taught literally
                        everywhere; Web architecture and protocols, not so much. I'm a much
                        better Web developer for having taken the time to learn the protocols
                        and architecture; but it gets exhausting having to explain to folks that
                        they aren't stupid or dumb, just ignorant, and that's why their ideas
                        are untenable.

                        Particularly for me -- I'm just not very good at diplomatic politesse,
                        even on those (rare) occasions when I do try... ;-)

                        My Uncle studied under Feynman at Cal Tech, and later spent decades
                        accrediting University-level Physics courses. Nowadays, the "Feynman
                        Lectures on Physics" is the de-facto standard for how introductory
                        Physics is taught (even when some other textbook is used). What's
                        needed is something along the lines of "Six Easy Pieces" for inclusion
                        in Web Design courses, for a solid grounding in the architectural
                        fundamentals of the Web; in an approachable fashion for non-architects,
                        as the basis for accreditation requirements.

                        Perhaps, if Web developers were taught the proper fundamentals of the
                        architecture, there'd be no reason to revisit -14 (along with any
                        number of other isses I'd thought long-settled). But I doubt it can
                        happen fast enough to head that off. As TBL points out, Web evolution
                        outpaces the ability to observe it; which makes the fundamentals all
                        the more imperative to keep that evolution from following a crash-and-
                        burn path, in the aftermath of which we look back in hindsight and see
                        that it was preventable because the fundamentals were right all along.

                        As it stands now, the "throw out HTTP and start over" crowd seems to be
                        gaining the upper hand, primarily due to the unpopularity of things
                        like media types, or -14. This way lies disaster, but what to do about
                        it?

                        -Eric

                        http://www.scientificamerican.com/article.cfm?id=long-live-the-web
                        http://en.wikipedia.org/wiki/Feynman_Lectures_on_Physics
                      • Jan Algermissen
                        ... Hmm, dunno, but AFAIR back in 2001 the idea was that the document (the image in this case) referenced by subjectIndicatorRef is sort of about the
                        Message 11 of 12 , Dec 1, 2010
                        • 0 Attachment
                          On Dec 1, 2010, at 11:55 PM, Alexander Johannesen wrote:

                          > On Thu, Dec 2, 2010 at 9:51 AM, Jan Algermissen <algermissen1971@...> wrote:
                          >> Note that simply stating <subjectIndicatorRef xlink:href="http://images/image-of-jim.jpg">
                          >> does not provide the ability to point to the image representation you receive upon a GET.
                          >
                          > Um, no, of course not, that's not in the realm of identity management,
                          > so I seriously don't understand your use of an image for a subject
                          > indicator?

                          Hmm, dunno, but AFAIR back in 2001 the idea was that the 'document' (the image in this case) referenced by subjectIndicatorRef is sort of 'about' the abstract concept (Jim). TopicMaps use(d) subjectIndicatorRef to distinguish between concept and document (sorry 'bout the fuzzy terms here).

                          >
                          >> IOW, a URI by definition never points to the representation. It always points to
                          >> the resource (the membership function) that maps to a set of representations or URIs over time.
                          >
                          > The concept here is inference about representation before resolving
                          > the URI to find out what it represents.
                          > In RDF it happens after
                          > resolving it, in Topic maps in terms of subject identification it
                          > happens before.

                          Not sure what 'inference about the representation' is. (But the sentence sounds real nice, anyway :-)

                          Jan


                          >
                          >
                          > Kind regards,
                          >
                          > Alex
                          > --
                          > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
                          > --- http://shelter.nu/blog/ ----------------------------------------------
                          > ------------------ http://www.google.com/profiles/alexander.johannesen ---
                          >
                          >
                          > ------------------------------------
                          >
                          > Yahoo! Groups Links
                          >
                          >
                          >
                        • Mike Kelly
                          ... Appreciate it s hard for you tell from way up there in your ivory tower, but an overwhelming majority would not even be aware of its existence. Not all
                          Message 12 of 12 , Dec 5, 2010
                          • 0 Attachment
                            On Wed, Dec 1, 2010 at 11:26 PM, Eric J. Bowman <eric@...> wrote:
                            > Dan Brickley wrote:
                            >>
                            >> This is roughly the topic known on the TAG mailing list as
                            >> http-range-14 and I shudder at the thought of revisiting it again...
                            >>
                            >
                            > Seems inevitable.  Don't get me wrong, I agree with the finding, due to
                            > my understanding of the architecture.  The problem is, if we were to
                            > poll Web developers we'd find that an overwhelming majority think it's
                            > wrong -- due to a lack of understanding of Web architecture.


                            Appreciate it's hard for you tell from way up there in your ivory
                            tower, but an overwhelming majority would not even be aware of its
                            existence.

                            Not all that surprising really, given that it's a solution to a
                            problem that doesn't actually exist in the Muggle world.

                            Cheers,
                            Mike
                          Your message has been successfully submitted and would be delivered to recipients shortly.