W3C home > Mailing lists > Public > public-hydra@w3.org > November 2015

Re: Modeling permissions with Hydra

From: Ryan Shaw <ryanshaw@unc.edu>
Date: Fri, 6 Nov 2015 14:35:28 -0500
Message-ID: <CAEvLMeToirNB2RszeMtvZRUq18dMiHYh1f2+A-N2g4cETQ7ueg@mail.gmail.com>
To: Karol Szczepański <karol.szczepanski@gmail.com>
CC: Dietrich Schulten <ds@escalon.de>, Asbjørn Ulsberg <asbjorn@ulsberg.no>, Tomasz Pluskiewicz <tomasz@t-code.pl>, Markus Lanthaler <markus.lanthaler@gmx.net>, Hydra <public-hydra@w3.org>
>> >> How about the combination of a static hydra:ApiDocumentation and
>> >> inline hydra:operation? Would the latter override the former? Is this
>> >> described anywhere?
>> >
>> > This has been discussed in length before.
>>
>> Can you please point me to this discussion?

The relevant thread starts here:
https://lists.w3.org/Archives/Public/public-hydra/2014Jun/0054.html

And continues here:
https://lists.w3.org/Archives/Public/public-hydra/2014Jul/0024.html
https://lists.w3.org/Archives/Public/public-hydra/2014Jul/0027.html

Thanks to everyone who has contributed to this thread; great discussion.

My takeaways so far:

1. There still doesn't seem to be consensus on the function of the API
documentation. Markus' position, if I understand correctly, is that
the API documentation is a kind of convenience or shortcut for
specifying state transitions; rather than or in addition to including
this information directly in representations. The advertised state
transitions from any specific representation are always the aggregate
of 1) the transitions specified in the representation itself PLUS 2)
any transitions specified in linked documentation.

2. However at least some others think the API documentation should be
interpreted as a kind of overview of what might be possible; a way to
document an API using RDF, but always subject to revision by the
information in an actual representation.

I'm less and less sure that I see the use of having potential state
transitions advertised anywhere *other* than in representations,
except as a way of generating human-readable documentation. A Hydra
client is always going to have to be ready to look for advertisements
of possible state transitions in individual representations anyway; so
what is the use of complicating client implementation by saying, "hey,
here are some other places to look for possible state transitions"?
Why not just leave it at "state transitions are advertised in
representations, period"? What would be the drawbacks of dropping
hydra:supportedOperation from the core vocabulary?

Ryan
Received on Friday, 6 November 2015 19:35:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 6 November 2015 19:35:58 UTC