Re: [core] Questions & Comments for PubSub updated Proposal

[Christian Amsüss <[e-mail]>]

Hello Jim, hello pubsub authors,

my personal take on this:

I think that most those points can addressed by a variation on the
proposal that has been floating but not made its way into the text yet:
Rather than all attributes being attached to the topic, some are on the
data resource. Compare the following to item 3.5:

    Request:

        GET </ps/topics/1234>

    Response:

        2.05 Content
        Content-Format: CoRAL

        rdf:type            <http://example.org/pubsub/topic>
        has-published-item  true
        publish             -> </ps/data/1234> [ method 3 ]
        created             dt'2019-07-08T15:35:00+0200'
        last-modified       dt'2019-07-08T15:35:00+0200'
        owner               <http://ericsson.example/people/ari>
        max-rate            50
        expires             dt'2019-07-15T15:35:00+0200'
        topic-data          </ps/data/1234> {
          unit                "Cel"
          rt                  "oic.r.temperature"
          # that was "topic-title" on the topic in proposal.txt
          title               "My Office Room Temperature"
          # that was "publisher" on the topic in proposal.txt
          owner               <http://ericcson.example/people/klaus>
          building            18
          floor               1
        }

We'd still need to, for all the properties involved, decide which terms
to use and where to attach them, but it completely sidesteps the topic
of inheritance (which would indeed be tricky -- the resource type of a
control resource is "pubsub topic control resource", if it's a
oic.r.temperature at the same time, that's ... odd). A good criterion
for whether something is an attribute of the control or the data
resource is the question "Does it matter whether this is used in a
pubsub context?": If it is, it should be on the control resource,
otherwise it's on the data resource.

This does still not quite answer this:

> 2.  It is not clear to me if a data node is supposed to be able to provide a
> CoRAL document for information that relates to it.

If someone only knows the data resource, there's no way back from there
to the control resource, and no way to get its metadata (that'd be a
PROPFIND-style operation probably, and I don't think we want that).
There are still CoRAL statements about the topic, but the easiest way to
obtain them is to look into the control resource's CoRAL document that
describes the topic as well as above. (Which is also how they could be
updated, by PATCHing that resource once a patch format for CoRAL is
there, or by PUTting back a modified representation, where the server
would reject changes it can't do, like the created date or the
topic-data URI).


Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom