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

Re: [rest-discuss] Terminology: "Resource Types"?

Expand Messages
  • Story Henry
    ... yes, both awol:Feed and awol:Entry are defined as classes. @prefix awol: . @prefix rdf:
    Message 1 of 44 , Sep 3, 2008
      On 3 Sep 2008, at 20:43, Stefan Tilkov wrote:

      > On 03.09.2008, at 17:56, Story Henry wrote:
      >> Use RDF then you don't get in a muddle about which words to use. Here
      >> in N3 with a mathematical theory to back you, you can say:
      >> @prefix awol: <http://bblfish.net/work/atom-owl/2006-06-06/#> .
      >> <http://yourdomain.com/postings/> a awol:Feed .
      >> <http://yourdomain.com/postings/1234> a awol:Entry .
      > But awol:Feed and awol:Entry "are" owl:Class, right?

      yes, both awol:Feed and awol:Entry are defined as classes.

      @prefix awol: <http://bblfish.net/work/atom-owl/2006-06-06/#> .
      @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

      awol:Entry rdf:type owl:Class;
      rdfs:label "Entry Class"@en;
      rdfs:comment "see §4.1.2 of the rfc 4287 spec"@en .

      awol:Feed rdf:type owl:Class;
      rdfs:label "Feed Class"@en;
      rdfs:comment "Container for feed metadata."@en .

      > If so, it appears that your answer to my question would be
      > "class" (I am aware that this means something different than a
      > type). Right?

      A class is a set of things. awol:Entry is of type owl:Class . So it is
      very close yes.


      > Thanks,
      > Stefan
    • Jan Algermissen
      Stefan, [yet another late reply to this one :-)] ... What about thinking about this in terms of kinds of application states ? Resources represent application
      Message 44 of 44 , Dec 9, 2009

        [yet another late reply to this one :-)]

        On Sep 2, 2008, at 11:04 AM, Stefan Tilkov wrote:

        > On 02.09.2008, at 08:59, Roy T. Fielding wrote:
        >> On Sep 1, 2008, at 10:41 PM, Stefan Tilkov wrote:
        >>> What do you call the concept of "classes" or "types" of resources in
        >>> your RESTful designs? E.g. when you decide to turn each "customer"
        >>> into its own identifiable resource - http://example.com/customers/
        >>> 1234
        >>> - what does http://example.com/customers/{id} describe? Both
        >>> "resource
        >>> class" and "resource type" would work, but don't seem really
        >>> convincing.
        >> We call them resources. If they had types, they would be strongly
        >> coupled to whatever expected that type.
        >> ....Roy
        > I don't want to suggest there's this kind of coupling (in fact I view
        > the lack of it as a strength, and this is why I'm unhappy with
        > "type"). What does the template identify? Resource, obviously, but
        > also a "group of similarly identified resources"?
        > It's not really the URI template connection I'm concerned with, I just
        > wonder whether there's a better term than "kind of …", as in "The
        > first step in designing an application interface should be to identify
        > the different kinds of resources you want to expose."

        What about thinking about this in terms of "kinds of application
        states"? Resources represent application states that the client can
        transition to. In M2M interactions the client code is a manifestation
        of the assumptions the client (developer) makes about the application
        state it reaches at a certain point.

        When I code a client for an ordering service, there will be (in some
        way) the coded assumption that after submitting an order there will be
        an application state that represents the order and (most importantly)
        provides the next transitions for 'operations' on that order (order
        change, order cancelation).

        I understand this in the sense that the client expects a certain "kind
        of application state" and this expectation corresponds to the reason
        why the server "exposes certain kinds of resources".

        Despite the fact that all resources are just resources this client
        side expectation about the next available transitions (which is what
        the "kind of application state" essentially means) is just not going
        to go away.


        > Thanks,
        > Stefan
        > --
        > Stefan Tilkov, http://www.innoq.com/blog/st/
        > ------------------------------------
        > Yahoo! Groups Links

        Jan Algermissen

        Mail: algermissen@...
        Blog: http://algermissen.blogspot.com/
        Home: http://www.jalgermissen.com
      Your message has been successfully submitted and would be delivered to recipients shortly.