Re: Creation of Containers

hello richard.

On 2012-11-07 16:29 , "Richard Cyganiak" <richard@cyganiak.de> wrote:
>All very true. A couple of things though.
>1. I don't think that media types are the answer here. In the RDF world,
>we've never used media types to distinguish anything besides the choice
>of serialization format for the payload, which inevitably is an RDF
>graph. The media type doesn't need to tell us any more than that -- how
>to get an RDF graph out of the bytes.

that's true as long as all you want to do is talk about RDF. if you want
to build meaningful RDF-based interactions, you need media types, that's
just how the web works. if you are really patient, reading
https://gist.github.com/2927644 might be interesting. essentially, we are
where application/xml was a while ago. if all you want to do is exchange
XML across the web transparently, application/xml is fine. if, however,
you want to build web-based interactions, you have to be able to talk
about the nature of these interactions on the level of the web, and that's
where media types are required. the fact that we just have application/rdf
(so to speak) today just means that people still see RDF as a data format,
not as something for building interactions on the web.

>2. In the RDF world, the semantics of the message is not communicated in
>a media type but in the RDF vocabularies used within the graph. RDF terms
>are globally unique, so this is unambiguous, unlike in say JSON where you
>need media types to distinguish your format from someone else's.

are you sure about that one? i think this is what started this thread: the
inability to distinguish whether a server should interpret something as an
opaque RDF graph (store this set of triples), or actually do something
based on the interaction semantics. that is exactly what media types give
you, and what RDF by definition can not do just by itself, since it is
only a data format: talking about the interaction semantics of what you
expect to happen when you exchange certain representations.

>3. I agree that the design shouldn't hardcode where you POST (or GET, for
>that matter). I dislike the ?firstPage and ?non-member-properties stuff
>in the current LDP draft. The answer to that can be quite simple though:
>Just state in the representation where the POST should go. In RDF, that's
>just a link. The semantics -- ³POST here to create a new XYZ², ³GET here
>to fetch the next page of property values² -- is in the link predicate.

sounds fine to me, that is what link relations allow you to do.

>4. This somewhat parallels the situation in HTML, where the interaction
>semantics are not in the media type but described in the payload --
>hyperlinks and forms. Although unlike in HTML, our ³forms² probably only
>need to cover a few hardcoded kinds of actions -- create a new resource
>in this container, go to the next page, stuff like that.

interaction semantics in HTML are in the media type, what you refer to are
the "human-oriented semantics" that are represented by anchor text and so
forth. if interaction semantics weren't part of HTML itself, the web as we
know it (and particularly any agents that crawl and index) would not exist.

cheers,

dret.

Received on Thursday, 8 November 2012 03:40:44 UTC