Re: "Basic profile" terminology ?

hello john.

On 2012-07-09 20:02 , "John Arwe" <johnarwe@us.ibm.com> wrote:
>Do tell... let's assume for the moment that your interpretation of the
>proposed direction were correct.  What considerations do the
>badly-implemented/adversarial clients bring in, from your point of view?
>I have ideas of what you MIGHT be hinting at, but until
> we get concrete it's impossible to tell if our thinking is similar,
>diametrically opposed, etc.

possible adversarial scenarios that come to mind are triple injection
where clients submit data that will be good for them in some context, such
as ratings or quality metrics or prices or whatever else are QoS-related
parameters in a given setting. possible badly implemented clients include
scenarios where clients submit inconsistent  data that will at least make
the data they submit worthless, and in bad cases will conflict with other
data in the platform and then renders other data worthless as well.
possible DOS scenarios are where clients intentionally submit data that is
know or they hope will make reasoning very slow, without any justification
as to why this data should be submitted in the first place. does this
illustrate things sufficiently? i guess i could produce a longer list of
potential problems, if that's required.

>>the service level i am talking about
>> is in no way specific to REST,
>If it's not specific to REST, am I to infer that it's at a higher level
>of abstraction?  If so, I'm forced to ask which/whose definition of REST
>is being used in this context; my default choice is "the REST
>architectural style as defined
> in Roy Fielding's PhD thesis", and if you're operating at a higher level
>of abstraction than "architectural style" I need to establish shared
>vocabulary for me to have any hope of interpreting your words as intended.

it's not a higher level of abstraction, it's a higher level of
generalization. direct data access (even in the real world, think or
libraries and archives and agencies) requires a lot of trust in those
granted that access; for everybody else, there needs to be a mediation
layer where people can request certain, more specific things, checks and
balances are in place, and if the request look ok, it will be serviced.
it's a very general pattern in pretty much any larger scale system sealing
with information, and REST is just one way for how this pattern can be
implemented in a specific way that happens to be nicely scalable and
evolvable.

>>it's simply what many different areas of
>> communication and data management systems discovered they need for
>> robustness and protection. 3-tier architectures are one example for that
>> kind of architecture.
>This makes it sound as if you are desirous for "standardization" of
>"things like 3-tier architectures" in this working group, and possibly
>their overlapping/common needs in areas like robustness and protection.
>Is that right?  Are there
> other aspects on your short list?

i think i have laid out what i could see this working group doing. not
standards, but looking at how to make services work for linked data. if
people mostly agree that this is not what we should be doing, we won't be
doing it.

>If you're saying that RF's thesis definition of REST is at a higher level
>of abstraction than HTTP, sure (plenty of commentary direct from RF on
>that).  I assume you're also aware that by far the most common de facto
>use of the term REST
> assumes HTTP as a transport and the Web as an architecture (hence 1
>level down in abstraction from REST-in-RF's-thesis).  If this thread is
>evidence of a model/metamodel discussion mismatch, things come into
>sharper focus for me at least.

actually, the most common de facto usage of the term REST in the REST
community is to use HTTP as an application protocol, which is what i am
arguing for.

>>of the main goals is to allow loose coupling by not designing RESTful
>> systems in a way where the interactions are based on specifics of the
>>data
>> model used in the service implementations.
>When you say "specifics of the data", I'm guessing (based on some of your
>other comments) that specifics at the media type level would be OK for
>you (it's XML; it's RDF/XML; it's JSON; whatever), and specifics of
>individual vocabularies (Dublin
> Core, Basic Profile Submission, SIOC, ADMS, whatever) would not be OK
>for you.  Is that a reasonable distinguishing example?

media type need a syntax, i guess that's a pretty safe starting point for
all of us. so there is no way around a specific choice on that level. in
REST, media types are based on hypermedia semantics, guiding clients via
typed links through the possible interactions with a service. if your
vocabulary does that, it's RESTful. if it doesn't, it's not.

>  So a RESTful system based solely on media types would be considered
>well-designed (loosely coupled) in your parlance, while one based
> on (in RDF terms) recognizing particular predicate URIs' semantic intent
>would not be considered well-designed (loosely coupled)?

both things look good to me, if the encoded semantic intent allows
discovery of actions that clients can take by following hypermedia links,
and if the intent also covers the expected behavior when following that
link.

>  That interpretation would seem consistent with the one above positing
>that the "service" discussion may be exposing a model/metamodel
> or "level of abstraction" disconnect.

my apologies, but this one i don't understand.

cheers,

dret.

Received on Monday, 9 July 2012 20:57:31 UTC