Profiles are not Schemas

[dret]

the current draft talks about a profile media type parameter, and recommends using it to link to a JSON schema. the existing https://tools.ietf.org/html/rfc6906 about profiles (that also talks about "profile" media type parameters) is not referenced, but at least there is some overlap. please consider that the idea of profiles (as specified in RFC 6906) is not to interlink instances and schemas. instead, the idea is that a profile identifies a set of rules applied to an instance which can be processed with or without knowing the profile-specific processing rules.

[awwright]

I agree the spec should be a bit more clear about this.

The "profile" media type parameter doesn't form a Web link as such, if we want to also provide the path to download the schema, that needs to be done in a Link header.

This also has the effect of allowing schemas to be defined at alternate locations, or allowing you to use schemas ids aren't network-addressable (like a URN).

Ideally, it seems, you should use both.

[dret]

On 2016-05-02 22:07, Austin Wright wrote:

I agree the spec should be a bit more clear about this.

that's good to hear, thanks!

The "profile" media type parameter doesn't form a Web link as such, if
we want to also provide the path to download the schema, that needs to
be done in a Link header.

the parameter as mentioned/defined in RFC 6906 is intended to reflect
the URI used for profile-typed links. it's simply a facility for how to
make profiles "visible" on the media type level, so that you can use
them more easily on the level of HTTP interactions.

This also has the effect of allowing schemas to be defined at alternate
locations, or allowing you to use schemas that aren't
network-addressable (like a URN).
Ideally, it seems, you should use both.

profile URIs are specifically defined to be identifiers and not
locators, so that applications using them can simply look at the profile
URI and then conclude that a given representation claims to conform to
the additional constraints of that profile.

schemas are a different matter as there can be various schemas for a
profile, and often a profile is not completely defined by a schema, but
there may be a schema that can be used to express (some of) the
constraints of the profile.

a recent mini-poll on twitter seemed to indicate that there is no good
fit for linking to a schema in terms of link relations, and people seem
to use a variety of link relations, none of them really being a great fit.

would it maybe make sense to create a new link relation "schema" (or
something to that effect) that would establish a more focused way of
linking a representation to a resource that represents (some subset of)
the constraints that govern the representation? it could be a pretty
small standalone spec a la RFC 6906, and i'd volunteer to start it, if
that sounds like a useful way to make this part of the JSON spec a bie
more clear.

(cc: @hvdsomp, this may be interesting for you as well.)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#26 (comment)

erik wilde | mailto:erik.wilde@dret.net |
| http://dret.net/netdret |
| http://twitter.com/dret |

[awwright]

Also, JSON Schema suggests using the "describedby" link relation, but this appears to be overloading POWDER, a vaguely similar specification, as "describedby" is specific to application/powder+xml.

[dret]

On 2016-05-03 12:56, Austin Wright wrote:

Also, JSON Schema suggests using the "describedby" link relation, but
this appears to be overloading POWDER, a vaguely similar specification,
as "describedby" is specific to application/powder+xml.

POWDER does not constrain the link target to be POWDER resources (and
note that RFC 5988 guidelines specifically say that registered link
relations must not constrain the media type of the context or the target
resources):

https://www.w3.org/TR/powder-dr/#assoc-linking

"This is a generic relationship type that does not of itself imply that
the link points to a POWDER document."

but apart from that, i find the definition to be much more about
providing metadata about a resource (such as "who's the author" and so
on), but the language is so extremely vague that you can pretty much
read into it whatever you like.

[azaroth42]

Also, the describedby link relation was updated by LDP to be explicitly less specific:
https://www.w3.org/TR/ldp/#link-relation-describedby

[handrews]

@azaroth42 , @dret : I think it's fine for describedBy to be vague about what it requires on the other end of the link. It's not just the describedBy relation that tells clients that the target is a schema. It is the media type application/schema+json that is set for the target representation that tells you that you now have a JSON Schema document that you can and should use to validate the data that supplied the describedBy link.

[awwright]

@dret Does #45 adequately address this issue?

[dret]

that's very well written, thanks for doing that.

On Sep 13, 2016, at 09:30, Austin Wright notifications@github.com wrote:
@dret Does #45 adequately address this issue?

[handrews]

@dret : Good enough to close this? :-)