Profile header or profile link?

[RubenVerborgh]

Should entity bodies be described by:

1. a Profile HTTP header?

2. a Link HTTP header with a profile relation?

3. both?

[dvh]

I know, this is exactly the reason why I came here :) But as we both seem to agree that CRS is not a profile-like thing, should we conclude that my challenge can't be solved using Profile negotiation?

[dret]

On 2017-04-26 13:51, Dimitri van Hees wrote:

I know, this is exactly the reason why I came here :) But as we both agree that CRS is not a profile-like thing, should we conclude that my challenge can't be solved using Profile negotiation?

i would say so. in particular because if you use RFC-GeoJSON, there is no such thing as CRS selection/negotiation anymore: it's WGS84 only.

[dvh]

About the GeoJSON RFC I'm glad this is also part of it, otherwise we couldn't use GeoJSON at all:

However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

In my interpretation this means that arrangements between clients and servers about the CRS being requested/provided are no part of the GeoJSON RFC but should be made somewhere else, e.g. with request/response headers. @lvdbrink, seems like OGC/W3C needs to come up with an alternative anyway ;)

[dret]

On 2017-04-26 14:11, Dimitri van Hees wrote:

However, where all involved parties have a prior arrangement,
alternative coordinate reference systems can be used without risk of
data being misinterpreted.

In my interpretation this means that arrangements between clients and servers about the CRS being requested/provided are no part of the GeoJSON RFC but should be made somewhere else, e.g. with request/response headers. @lvdbrink https://github.com/lvdbrink seems like OGC/W3C needs to come up with an alternative anyway ;)

i intensely disliked this language in the spec when it was proposed. it assumes that there is such a thing as a "safe context" where you can still weasel your way around the CRS issue. i think that's partly unrealistic self-delusion and partly the political compromise to still allow (but refuse any responsibility for) alternative CRS. but we're getting seriously off-topic here... ;-)

[dvh]

True, I'm off to https://github.com/w3c/sdw ;)

[larsgsvensson]

On 2017-04-26 10:33, Lars G. Svensson wrote: I'm not saying that the schema /defines/ the profile, I only say that for some uses we /need/ a schema. And while the user /could/ write a schema I'd say that if the profile publisher also publishes a schema that implements the profile, that would improve interoperability.

you may need a schema, but how to find it is a different matter. profile URIs are identifiers. so logically speaking, you would need to find the specification document for the profile, and then see if that contains any authoritative schema. markus lanthaler had similar questions and concluded that a profile registry would help with making profile specs easier to find. the current contents of that registry speak for itself.

https://www.iana.org/assignments/profile-uris/profile-uris.xhtml

Indeed not very much in there...

but that doesn't mean that the idea itself doesn't have merit. only that maybe a central registry isn't what's really needed here. but come to think of it, profile URIs are a web concept and with or without registry should be the kinds of things people care about when they manage their API landscape. adding to web concepts!

I'm not assuming that profiles /always/ have one authoritative schema. But it would be helpful for profile users if there is a standardised mechanism that allows them to find schemas associated with a certain profile. That could be done using the |Link| header, too:

that's assuming there's a standard way to first find anything from a profile URI. there isn't. it's just an identifier.

Yes, I shouldn't assume that things are as webby as they should be... If the profile URI is e. g. a URN, then there isn't much to do (except perhaps trying to use the IANA registry), but if the profile has an http URI and there is a document available on the web, then it's at least theoretically possible that the publishers can use a standardised way to point agents at schema definitions.

(that would require the registration of the relation type "schema", but that should be easy; I find it more worrysome that I couldn't figure out a way to say that the first schema is an XSD document, the second a RELAX NG, the third uses SHACL (in Turtle) and the fourth ShEx (in JSON-LD)).

the schema link relation was suggest many times, but apparently there never was enough momentum to really get it spec'ed and registered. i find that one of the more promising ideas (but quite different from a profile). if you think that would be worth pursuing, i'd be willing to help.

Let's see where this spec takes us and then we can decide.

regarding the missing schema language media types: that's indeed a bit unfortunate and part of the general problem that many spec authors don't think about (and aren't encouraged when the specs go through review processes) how their vocabularies can be identified on the web level.

Do you think there is a solution to that problem at all or is everything lost already?

[larsgsvensson]

BTW, I just saw in the PR for Linked Data Notifications that they use the NS Document for ActivityStreams as a JSON-LD profile URI, adding it to the media type in the Content-Type headers

POST /inbox/ HTTP/1.1
Host: example.org
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

Cf. https://www.w3.org/TR/2017/PR-ldn-20170321/#sending-notification-request. To me, this feels a bit weird since the namespace document defines a term "profile" but never says that it is a profile (nor what restrictions it imposes...)

[dret]

On 2017-04-27 10:00, Lars G. Svensson wrote:

that's assuming there's a standard way to first find anything /from a
profile URI/. there isn't. it's just an identifier.

Yes, I shouldn't assume that things are as webby as they should be...

not every identifier is a link. that's very webby. use links when you want to link. use identifiers when you want to identify. two different tools for two different goals.

regarding the missing schema language media types: that's indeed a
bit unfortunate and part of the general problem that many spec
authors don't think about (and aren't encouraged when the specs go
through review processes) how their vocabularies can be identified
on the web level.

Do you think there is a solution to that problem at all or is everything lost already?

you could write up drafts for registering specific schema language media types. maybe that's actually a worthwhile thing to do, i had the same issue with XSD many times.

for the specs still under development, just raise issues with their editors. but then again, for the RDF-based ones, minting media types is not something these communities ever do (unless there's a new RDF serialization), so you might get some resistance to this idea. for other communities i'd say they probably are open to the idea, but getting enough momentum behind these drafts would take quite a bit of energy and persistence.

[dret]

On 2017-04-27 10:12, Lars G. Svensson wrote:

BTW, I just saw in the PR for Linked Data Notifications https://www.w3.org/TR/ldn/ that they use the NS Document for ActivityStreams https://www.w3.org/ns/activitystreams as a JSON-LD profile URI, adding it to the media type in the Content-Type headers

|POST /inbox/ HTTP/1.1 Host: example.org Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams" Content-Language: en |

Cf. https://www.w3.org/TR/2017/PR-ldn-20170321/#sending-notification-request. To me, this feels a bit weird since the namespace document defines /a term/ "profile" but never says that it /is/ a profile (nor what restrictions it imposes...)

well. JSON-LD took the profile concept and ran with it. to my mind, they are misunderstanding and misusing it in the same way that has started our long conversation here. but they still wanted to do it this way and did it.

[larsgsvensson]

you could write up drafts for registering specific schema language media types. maybe that's actually a worthwhile thing to do, i had the same issue with XSD many times.

Thinking of it, would you agree that XSD could be seen as a profile of XML? The specification does add syntactic and semantic constraints...

for the specs still under development, just raise issues with their editors. but then again, for the RDF-based ones, minting media types is not something these communities ever do (unless there's a new RDF serialization), so you might get some resistance to this idea. for other communities i'd say they probably are open to the idea, but getting enough momentum behind these drafts would take quite a bit of energy and persistence.

The upcoming ODRL vocabulary specification (soon going to CR) also talks about how to create and document profiles and I think they've got it right. They could serve as an good use case since they specify three different encodings of their model: RDF/OWL, XML and JSON-LD.

[dret]

On 2017-04-28 14:35, Lars G. Svensson wrote:

you could write up drafts for registering specific schema language
media types. maybe that's actually a worthwhile thing to do, i had
the same issue with XSD many times.

Thinking of it, would you agree that XSD could be seen as a profile of XML? The specification does add syntactic and semantic constraints...

i think we're going in circles a bit ;-) XSD is a language with its own semantics. it just happens to have an XML serialization, but that doesn't make it a profile. it just means that there is a schema for it (the wonderfully named "schema for schemas") that you can use if you want to understand how the XSD vocabulary is serialized in XML.

what matters for XSD is not the XML level at all. it's what you could call the "XSD infoset", i.e. the model that is expressed via an XML serialization. in a previous life i even devised a non-XML syntax for XSD because the XML syntax annoyed me to no end: https://www.xml.com/pub/a/2003/08/27/xscs.html

for the specs still under development, just raise issues with their
editors. but then again, for the RDF-based ones, minting media types
is not something these communities ever do (unless there's a new RDF
serialization), so you might get some resistance to this idea. for
other communities i'd say they probably are open to the idea, but
getting enough momentum behind these drafts would take quite a bit
of energy and persistence.

The upcoming ODRL vocabulary specification (soon going to CR) also talks about how to create and document profiles https://www.w3.org/TR/odrl-model/#profile and I think they've got it right.

thanks for that link! yes, ODRL is actually talking about profiles as defined by RFC 6906: these profiles can both constrain and extend the underlying ODRL model. any resource using the model is a proper ODRL resource and can be processed as such; the profile simply indicates the specific ways in which this ODRL resource is using the language.

They could serve as an good use case since they specify three different encodings https://www.w3.org/TR/odrl-vocab/#encodings of their model: RDF/OWL, XML and JSON-LD.

nice. and in their case it probably would make a lot of sense to identify the profile independently of the ODRL serialization. after all, the profile talks about how ODRL is used, and not how it is serialized.