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

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Christian Amsüss <[e-mail]> 
Sent: Thursday, August 1, 2019 1:46 AM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]
Subject: Re: [core] Questions & Comments for PubSub updated Proposal

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.

[JLS] Yes - That is very similar to the way that was thinking.  I had not
gone as far as renaming some of the fields so that there is more consistency
but that makes things even better.

There is the interesting question of what the target is for a creation post,
a patch would use the correct target, but I think that this could be done as
[ path.type: relative-path]  which is the closest that I can see to being
the equivalent of "." which would make sense.

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).

[JLS] Right - somebody who know both that this was a pub-sub server and
understood CoRAL could do this with 

REQUEST

FETCH </ps/topics>

rdf:type            <http://example.org/pubsub/topic>
topic-data         </ps/data/1234>

This would find and return the information about the topic based on the
topic-data path.  If you just do link format then you are out of luck.

Jim



Best regards
Christian

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