Skip to content

Instantly share code, notes, and snippets.

@JeniT
Created June 14, 2012 01:40
Show Gist options
  • Save JeniT/2927644 to your computer and use it in GitHub Desktop.
Save JeniT/2927644 to your computer and use it in GitHub Desktop.
Possible way to provide POSTable URI in RDF
<http://www.amazon.com/gp/product/B000QECL4I>
eg:reviews <http://www.amazon.com/product-reviews/B000QECL4I> ;
eg:order "http://www.amazon.com/gp/product/B000QECL4I{?copies}" ;
.
and then the definition of eg:reviews would say "the object of this property
provides reviews of the subject of this property" and the definition of
eg:order would say "POST to the URI generated by expanding the URI template
value of this property where the copies variable is the number of copies to
be ordered"
dunno on question of whether URI template should have its own datatype
@dret
Copy link

dret commented Jun 14, 2012

@JeniT, i am just repeating my question here, because i really would like to see how your scenario would work. you say that "you don't need to have separate media types for each combination of vocabularies used in a particular message: you just say that the message is of an RDF media type and locating the definition of the meaning of that particular message then follows naturally." once again, for GETting RDF that might work, but how does that work when a client is supposed to PUT something? the client has application state (a rather abstract "order intent") and needs to get that to the server. representing that order intent needs a framework where the client knows which order representation is acceptable to the server. there could be various order representations in RDF that a client knows about (because it may be capable of talking to different services, for example), so if the "order" link simply is described by "send me some RDF", how does the client decide which order vocabulary to use? please explain to me how you see this working, i really want to understand this part of the puzzle.

@JeniT
Copy link
Author

JeniT commented Jun 15, 2012

@dret I think I see the point you're making: you need to express what you can POST or PUT to a given URI using some method that makes those restrictions discoverable by HTTP machinery. I've looked at HTTPbis and I can't immediately see where that machinery is. You imply that there's something like an "Accept-Content-Types" header that enables a server to list acceptable content types for POST/PUTting, but I can't see it. Can you point me at it or if there isn't one, explain how a server that supported POSTing using a particular +json media type would express that constraint (I guess in response to an OPTIONS request on the URI)?

@dret
Copy link

dret commented Jun 15, 2012

i'm afraid you're right that for a reason i cannot think of right now, Accept is a request header only, which means you could put the list in a 415 error document, but that would be convention and not the standard. so no, there is no machinery communicating the list of acceptable media types back to the client in case of an error. but looking at the first part of the question, how to even know what to submit, there is a way how that state is transferred to the client (here's the book info, there's the order link, and here's what to POST to it as payment info), and my question still is how you would communicate that expectation to the client. the client needs to know what it is expected to submit, so just telling it "submit RDF" is not sufficient.
asking the same question in a different way: in existing RDF services, how does that work? does a client just "know" what it is supposed to POST/PUT to a given URI if it wants to interact with the service in the context of an application? how does it acquire that knowledge? in media types, that knowledge would be coupled to the link relation, either implicitly (submit something using this vocabulary when traversing such a link), or explicitly (often using link/@type or link/@accept attributes in XML vocabularies). this allows clients to choose according to their capabilities and preferences, if servers provide alternatives, and those alternatives are communicated through media types. new capabilities may show up when a server starts supporting additional interactions, but clients often need to be updated (learning about the new media types) to be able to take advantage of these new capabilities.

@ldodds
Copy link

ldodds commented Jun 15, 2012 via email

@dret
Copy link

dret commented Jun 16, 2012 via email

@JeniT
Copy link
Author

JeniT commented Jun 16, 2012 via email

@dret
Copy link

dret commented Jun 18, 2012 via email

@aharth
Copy link

aharth commented Jul 10, 2012

Hi,

why not use SPARQL (or rather, graph patterns) to describe inputs, outputs and relation between input and output? Most of the current approaches on http://linkedservices.org/ use that type of description.

HATEOAS URIs could just be embedded into the RDF that's returned.

Best regards,
Andreas.

@cygri
Copy link

cygri commented Nov 8, 2012

Interesting discussion! Thanks @JeniT, @dret and @ldodds! And no, I'm still not convinced that there's value in defining new media types for every application. That's an anti-pattern needed to cope with formats that don't have hypermedia capabilities and can't be extended in a standard way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment