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?

[larsgsvensson]

If I remember the discussion in Amsterdam correctly, the idea was to use the Profile header and the Link header with the keyword "profile" (not rel="profile" but rel="self"; profile="<urn:example:whatever>")

[RubenVerborgh]

not rel="profile"

Then we go against RFC6906, which seems problematic.

[larsgsvensson]

Do we know how widely deployed RFC 6906 is? (or put differently, is it really a problem if we propose another solution to the problem RFC 6906 tries to solve if the new solution is better (which I think it is since we can supply more information about the referenced resource, e. g. the combination of media type and profile(s)))?

[RubenVerborgh]

We'd have to very carefully weigh our options.

We should ask @dret if he knows about usage statistics of RFC6906.

[larsgsvensson]

OK, can you contact him?

[RubenVerborgh]

Yes, the ping above should work.

[dret]

On 2017-04-18 18:24, Ruben Verborgh wrote:

We'd have to very carefully weigh our options. We should ask @dret https://github.com/dret if he knows about usage of RFC6906.

what exactly is the question? not sure exactly what this is about, but it seems that it is more about schemas/vocabularies than about profiles. http://dret.typepad.com/dretblog/2016/05/resource-profiles-and-types.html was an attempt a while ago to clarify what RFC 6906 is all about, but i still see it being used in ways that were not intended, using it for schema/vocabulary identification instead of profile identification.

btw, http://webconcepts.info/specs/IETF/RFC/6906 only defines a link relation type, and no HTTP header field.

in terms of stats of where and how the link relation type used, i don't have any that i could share, except for talking to people who are using it or considering using it.

[hvdsomp]

Hey Erik, thanks for commenting. Unfortunately, despite your blog post, I (and I assume others) remain in the dark as to what "profile" really is about and what it is not about, despite the RFC, your blog post and your response to my comment to it. I'm not trying to be thick, just plain honest. What would, for example, help is to show what language in the RFC excludes "profile" from being used for e.g. schema.

Cheers

Herbert

[dret]

On 2017-04-20 15:37, Herbert Van de Sompel wrote:

Hey Erik, thanks for commenting. Unfortunately, despite your blog post, I (and I assume others) remain in the dark as to what "profile" really is about and what it is not about, despite the RFC, your blog post and your response to my comment to it. I'm not trying to be thick, just plain honest. What would, for example, help is to show what language in the RFC excludes "profile" from being used for e.g. schema.

i can try again, but i think i now have a long history of not being able to explain very well what profiles were designed for. generally speaking, the work is motivated by the API space and more specifically by http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html as a pattern for API design.

the "Meaningful Core Semantics" are established by a schema and its design for openness and extension. this schema might be something like HTML or atom (both examples from the RFC). this schema is not what is identified by a profile. it is the schema that establishes the API and in most cases might be identified by media type.

specific ways of using the "Well-Defined Extension Points" and the "Well-Defined Processing Model" (which are established by the schema) might be identified by a profile URI. the profile URI is just a way how it can be signaled that the API is utilized in a specific way. typically it is not even necessary to signal it this way, but it may be useful to do so (examples from the spec: "this feed is not just a feed, it uses the extension capabilities of feeds in a way that turns them into podcasts"). note that the schema for a feed (or an hcard HTML page) is still the atom schema or the HTML DTD. the profile is not identifying a schema. the media type remains the same as well. being able to surface the "podcast-ness" of a feed is nothing but a convenience function that may be more convenient than having to programmatically check whether a feed is a podcast or not.

[larsgsvensson]

Hi Erik and thanks for your thoughts.

Like @hvdsomp, I'm also a bit at odds figuring out exactly what a profile is. The posts you've shared provide some clarification, but still leaves some questions open.

I'm particularly interested in your views on the choice of "profile" vs "schema" since you use both terms in your posts. What I want to be able to exchange information on are things like XML Schemas, SHACL shapes or Dublin Core Application Profiles, allowing a server to say that an XML document would validate against a specific XSD document, or an RDF representation (irrespective of serialisation (RDF/XML, Turtle...)) would adhere to the constraints specified in a SHACL or ShEx document. Would you consider the SHACL, ShEx or XSD files to be profiles or schemas?

In the first version, the I-D was about "schema negotiation" (cf #1) and later we decided to call it "profile negotiation" instead. Perhaps we need to reconsider that. I've re-opened #1 until we've decided on that.

[RubenVerborgh]

I would propose to follow the description of a profile from RFC 6906:

For the purpose of this specification, a profile can be described as additional semantics that can be used to process a resource representation, such as constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics.

And from XML Schema:

An XSD schema is a set of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element and attribute information items (as defined in [XML Infoset]), and furthermore to specify additional information about those items and their descendants.

Following the above, it seems to me that schemas are a proper subset of profiles. In other words, everything that is a schema is also a profile, but not every profile is a schema.

Given that we likely also want to support several JSON scenarios, and that most cases there do not have formal schemas that allow validity assessment, I would opt for "profile". Also, I see no need to restrict us unnecessarily to schemas, when we can also support the wider set of profiles with the same effort.

If we want our own definition of "profile", I would (following my SDSVoc contribution) propose something like:

A profile is a set of structural and semantic constraints of representations, which can apply in addition to syntactic, structural, and semantic constraints defined by a MIME type.

[dret]

On 2017-04-24 12:58, Lars G. Svensson wrote:

Like @hvdsomp https://github.com/hvdsomp, I'm also a bit at odds figuring out exactly what a profile is. The posts you've shared provide some clarification, but still leaves some questions open.

like i said, i seems to have a problem expressing this. one of the main aspects of profile said very explicitly in the RFC is that it is an identifier, not a link. these are different things.

a profile may be implemented by zero, one, or several schemas.

• things such as IJSON and canonical XML have no schemas, but closely match the definition of a profile.

• things such as podcasts also have no schema. the schema of a podcast is still the feed schema.

• some profiles may be defined by a schema. like all schemas, it will only represent a subset of the meaning of the profile. the profile identifies the concepts, a schema may be used to link to an incomplete representation of how they can be defined in some schema language.

• if people care enough they might even have multiple schemas for one profile, as depending on the schema language, you often can make various user communities happy, and can represent different aspects of the profile. in XML land, for example, for quite a while people had DTD and XSD, or XSD and RELAXNG, which were different schemas, but sometimes were used to implement the same "profile".

I'm particularly interested in your views on the choice of "profile" vs "schema" since you use both terms in your posts. What I want to be able to exchange information on are things like XML Schemas, SHACL shapes or Dublin Core Application Profiles, allowing a server to say that an XML document would validate against a specific XSD document, or an RDF representation (irrespective of serialisation (RDF/XML, Turtle...)) would adhere to the constraints specified in a SHACL or ShEx document. Would you consider the SHACL, ShEx or XSD files to be profiles or schemas?

schemas. you can define to implement a profile in any of these. or, as pointed out above, you can implement one profile in various schemas (which in practice happens relatively often). just think about DSDL and its (unfinished) vision of "schema pipelines"; that might give you a good framework of why a profile is just an identifier, and then you can easily have multiple schemas if that's how you decide to implement your profile.

In the first version, the I-D was about "schema negotiation" (cf #1 https://github.com/ProfileNegotiation/I-D-Accept--Schema/issues/1) and later we decided to call it "profile negotiation" instead. Perhaps we need to reconsider that. I've re-opened #1 https://github.com/ProfileNegotiation/I-D-Accept--Schema/issues/1 until we've decided on that.

it seems to me that you're mixing things, at least in terms how i see and use these concepts. you are trying to do profile negotiation, but you are thinking in terms of "there must be one resource that represents the profile in a machine-processable way that is the one true representation of the profile". that is not how the world works in the places where i come from, and hence this perspective makes things problematic.

i know that this is a gigantic can of worms, but XMLNS/XSD have the right framework: concepts are identified by an identifier (a namespace URI). an XSD schema (or multiple XSD schemas, for that matter, i have seen many examples of this) then defines a schema that implements that namespace. what matters is not how you find the schema (that turned out to be a non-problem in practice, because for security reasons nobody starts downloading and using random schemas anyway), but how you find out which concepts are referred to in a document. for that you need the namespace URI, but not the xsi:schemaLocation.

in practice, people outside of closely knit circles always ignored xsi:schemaLocation. what happens in the vast majority of cases is that implementations pivot on the vocabulary they see (i.e., the namespace URI), because that identifies the vocabulary that is being used. assuming that there is a single true and trusted location where to find the schema causes major headaches along a variety of axes, and simply never took off (for very good reasons, i think).

to achieve the biggest impact in practice my suggestion would be to go for profiles, but to treat them in their RFC 6690 spirit: they are identifiers only, (and profiles can be implemented by 0-n schemas, but these outside of the scope of profile negotiation).

[dret]

Following the above, it seems to me that schemas are a proper subset of profiles. In other words, everything that is a schema is also a profile, but not every profile is a schema.

profiles and schemas are different things. a schema is one possible way to implement a profile. there are other ways as well.

[RubenVerborgh]

but you are thinking in terms of "there must be one resource that represents the profile in a machine-processable way that is the one true representation of the profile".

That is not the case, so we should be good then.

[larsgsvensson]

like i said, i seems to have a problem expressing this. one of the main aspects of profile said very explicitly in the RFC is that it is an identifier, not a link. these are different things.

OK, sloppy terminology on my side: the proposal we're discussing here is about profile (or schema...) identifiers, not about links

[larsgsvensson]

to achieve the biggest impact in practice my suggestion would be to go for profiles, but to treat them in their RFC 6690 spirit: they are identifiers only, (and profiles can be implemented by 0-n schemas, but these outside of the scope of profile negotiation).

I'd say that even if profiles and schemas are different things, we cannot completely ignore the schema negotiation. When a client has requested (and received) a resource it also might need to find a corresponding schema against which it can validate the resource and that requires negotiation, too (e. g. for an XML document to decide if the profile should be implemented by a DTD, an XSD or a RELAX NG document, or for an RDF document if the schema is implemented by a SHACL or a ShEx shape).

[RubenVerborgh]

When a client has requested (and received) a resource it also might need to find a corresponding schema against which it can validate the resource and that requires negotiation, too

So how about we use the same mechanism for negotiation profiles and schemas? (Given that "a schema is one possible way to implement a profile.")

[dret]

On Apr 24, 2017, at 16:08, Lars G. Svensson notifications@github.com wrote: OK, sloppy terminology on my side: the proposal we're discussing here is about profile (or schema...) identifiers, not about links.

i think you have to ask yourself what scenario you want to support: if for example from the profile RFC you are looking at the podcast, there is no schema. so being able to negotiate schemas wouldn't help. if you want to be able to negotiate profiles that might have multiple schemas, being able to negotiate schema identifiers wouldn't help either.

and to be honest, i have a hard time imagining use cases where schema negotiation would be useful. schemas are just implementations that should be able to be changed or switched without affecting what concept they implement.

either way: start with these use cases, and only then think about terminologies and what kind of specs you might be able to build on.

[dret]

On Apr 24, 2017, at 16:41, Ruben Verborgh notifications@github.com wrote: So how about we use the same mechanism for negotiation profiles and schemas? (Given that "a schema is one possible way to implement a profile.")

how would that reflect situations where the number of schemas fir a profile is != 1, or where different resources might use different schemas to implement a profile?

[RubenVerborgh]

how would that reflect situations where the number of schemas fir a profile is != 1

The idea is that multiple profiles/schemas can be indicated.

[dret]

On Apr 24, 2017, at 16:27, Lars G. Svensson notifications@github.com wrote:

I'd say that even if profiles and schemas are different things, we cannot completely ignore the schema negotiation. When a client has requested (and received) a resource it also might need to find a corresponding schema against which it can validate the resource and that requires negotiation, too (e. g. for an XML document to decide if the profile should be implemented by a DTD, an XSD or a RELAX NG document, or for an RDF document if the schema is implemented by a SHACL or a ShEx shape).

as mentioned earlier: on the web, few clients will trust schema links and download and use schemas. that's s huge security issue. and quite a number of languages have schema hints (DTD and XSD for example).

if there is significant demand, maybe a generic schema hint/link might help. i think there were several proposals over the past decade, but they all died. imho the reason is that clients almost always use local info to validate. i've never ever seen a production system blindly loading schemas at runtime and then using them.

my suggestion: wait and see if this really is needed outside of tightly coupled communities.

[dret]

On Apr 24, 2017, at 17:22, Ruben Verborgh notifications@github.com wrote:

how would that reflect situations where the number of schemas fir a profile is != 1

The idea is that multiple profiles/schemas can be indicated.

how would you know which ones are profile identifiers and which ones are schema links? per RFC, multiple profile URIs mean that multiple profiles are signalled as being present by using multiple identifiers.

[RubenVerborgh]

how would you know which ones are profile identifiers and which ones are schema links?

The assumption is that the client has them hard-coded.

per RFC, multiple profile URIs mean that multiple profiles are signalled as being present by using multiple identifiers.

+1

[dret]

On 2017-04-24 17:28, Ruben Verborgh wrote:

how would you know which ones are profile identifiers and which ones
are schema links?

The assumption is that the client has them hard-coded.

what do you mean by this? how would a client know if it encounters an unknown URI if this is a profile identifier it does not know or a schema link it can follow to find a schema resource?

[RubenVerborgh]

how would a client know if it encounters an unknown URI if this is a profile identifier it does not know or a schema link it can follow to find a schema resource?

With the current design, it would not. We can add this to requirements (#16) if this is a necessity.

[dret]

On Apr 24, 2017, at 18:32, Ruben Verborgh notifications@github.com wrote: how would a client know if it encounters an unknown URI if this is a profile identifier it does not know or a schema link it can follow to find a schema resource?

With the current design, it would not. We can add this to requirements (#16) if this is a necessity.

i must be missing something if that's something that seems like an optional extra.

[RubenVerborgh]

The current scenario is:

• clients ask for profiles
• server responds with a subset of those profiles

So clients know what to expect.

[dret]

On 2017-04-24 22:17, Ruben Verborgh wrote:

The current scenario is:

• clients ask for profiles
• server responds with a subset of those profiles

So clients know what to expect.

in terms of profiles, requesting profiles means stating a preference that the server might or might not satisfy. that's the whole point of profiles: they are always optional, and clients may have certain preferences (if you can embed metadata via hcard in this HTML, that would be ideal, but since we're using HTML, we can continue either way), but they should be able to proceed even if those preferences aren't met.

that's the API angle of it: the stable core means that applications can be built around an API. profiles may be used to signal the presence of certain extensions, but they aren't required and the foundation of interactions always is the stable core of the API.

[larsgsvensson]

in terms of profiles, requesting profiles means stating a preference that the server might or might not satisfy. that's the whole point of profiles: they are always optional, and clients may have certain preferences [...] but they should be able to proceed even if those preferences aren't met.

There might be a difference here between "processing" and "make something sensible out of" a resource. A client might be able to process (i. e. parse) an XML document correctly but it might not be able to make sense out of it since the document has a structure that the client cannot semantically understand (e. g. uses elements the client doesn't know the meaning of).

that's the API angle of it: the stable core means that applications can be built around an API. profiles may be used to signal the presence of certain extensions, but they aren't required and the foundation of interactions always is the stable core of the API.

To me http is the API and my vision is that clients and servers can use http content negotiation to decide which representation is the best one, including what profile the resource should adhere to. In that respect profiles are more than mere extensions but a basic building block just as media types are. If a client says it can handle the profile <urn:example:foo> there's no use in sending it a resource adhering to <urn:example:bar> just as it makes no sense to send it JSON when it asks for XML. That's why my first draft says that it should be possible to work with q-values when negotiating the profiles and that a server may return 406 if it cannot supply the profile the client asks for.

[RubenVerborgh]

in terms of profiles, requesting profiles means stating a preference that the server might or might not satisfy. that's the whole point of profiles: they are always optional, and clients may have certain preferences (if you can embed metadata via hcard in this HTML, that would be ideal, but since we're using HTML, we can continue either way), but they should be able to proceed even if those preferences aren't met.

+1, that's what we want

[dret]

On 2017-04-25 13:35, Lars G. Svensson wrote:

There might be a difference here between "processing" and "make something sensible out of" a resource. A client might be able to process (i. e. parse) an XML document correctly but it might not be able to make sense out of it since the document has a structure that the client cannot semantically understand (e. g. uses elements the client doesn't know the meaning of).

very true. that's why profiles are for specific uses. atom isn't a profile of XML, because it's something categorically different. it just happens to use XML as its serialization. podcasts however are a profile of atom because every podcast is an atom feed and you can do something meaningful with it even when you understand how feeds work, even if a feed you're looking at isn't a podcast.

To me http /is/ the API and my vision is that clients and servers can use http content negotiation to decide which representation is the best one, including what profile the resource should adhere to. In that respect profiles are more than mere extensions but a basic building block just as media types are.

that may be your idea of profiles but it's not mine and it's not what the RFC was written for, hence the language about profiles being specific and optional constraints/extensions of vocabularies.

frankly, it seems to me you're trying to engineer around one of RDF's oddities, which is the assumption that everything is just RDF (and not a specific vocabulary that people have agreed on and that is identified by media type), and media types are only for signaling serialization differences of the metamodel. there's a long history of attempts to better reconcile this design quirk with how the rest of the web works (most attempts i have seen used the "schema" terminology for that, probably because of RDFS). to me, that's a specificity of how RDF works and is getting used, so maybe this problem would be better addressed on the RDF level.

If a client says it can handle the profile || there's no use in sending it a resource adhering to || just as it makes no sense to send it JSON when it asks for XML.

if clients use feeds and one says that for media feeds it would prefer them in the podcast profile, then it does make sense to send it a media feed that's not using the podcast profile, because the whole scenario is based on using feeds.

of course i cannot keep you from calling what you're looking for "profiles", but it seems to me you're having something else in mind, at least in terms of how i see that concept.

That's why my first draft says that it should be possible to work with q-values when negotiating the profiles and that a server may return 406 if it cannot supply the profile the client asks for.

but that's exactly what media types are for and is exactly what media types are doing. it seems to me you're layering a second media type layer on top of the existing one. as mentioned above, to me the reason why you're doing this is RDF's specific way how to use media types, so i am not sure that a web-level mechanism is needed here.

using my own terminology, i think what you're trying to do is doing vocabulary negotiation for a scenario where vocabularies can be freely combined. on the non-RDF web, those vocabularies would be negotiated via media types. writing this it seems to me that "vocabulary" maybe a good term here, avoiding the baggage and implications of both "schema" and "profile".

[RubenVerborgh]

frankly, it seems to me you're trying to engineer around one of RDF's oddities, which is the assumption that everything is just RDF

This draft is not intended to be specific for RDF at all (see #13).

A "profile" could also signal, for instance, the presence of a certain key/value pattern in a JSON document. It could also be HTML with a certain microformat. It could be many, many things, only a couple of which are specific to RDF (certain vocabularies, certain JSON-LD frame).

[dret]

On 2017-04-25 14:28, Ruben Verborgh wrote:

A "profile" could also signal, for instance, the presence of a certain key/value pattern in a JSON document. It could also be HTML with a certain microformat. It could be many, many things, only a couple of which are specific to RDF (certain vocabularies, certain JSON-LD frame).

the problem is the different perspective on what a profile is. iff you have in mind to use profiles in their RFC 6906 flavor, then the mechanism would be an optional hint. it would tell the server "i'd prefer that specific profile if that is applicable to the resource i am requesting and you're capable of producing it for me. if not, feel free to ignore it and send me whatever you think is appropriate. the media type will make sure we're still on common ground."

[RubenVerborgh]

Yes, that's what we aim to do.

[dret]

On 2017-04-25 14:34, Ruben Verborgh wrote:

Yes, that's what we aim to do.

i sense a disconnect between what you're saying and what lars is talking about. maybe it would be good to clarify how this mechanism is supposed to be useful and to work on the web in general.

[larsgsvensson]

frankly, it seems to me you're trying to engineer around one of RDF's oddities, which is the assumption that everything is just RDF

This draft is not intended to be specific for RDF at all (see #13).

+1 (that's why I use XML examples)

A "profile" could also signal, for instance, the presence of a certain key/value pattern in a JSON document. It could also be HTML with a certain microformat. It could be many, many things, only a couple of which are specific to RDF (certain vocabularies, certain JSON-LD frame).

JSON is definitely a use case (particularly since Ruben's talk in Amsterdam was titled "Your JSON is not my JSON". The reason I use XML examples (with profiles implemented as DTDs, XSDs and RELAXNGs) is simply that I don't know enough about the capabilities of JSON Schema.

[dret]

On 2017-04-25 16:09, Lars G. Svensson wrote:

JSON is definitely a use case (particularly since Ruben's talk in Amsterdam was titled "Your JSON is not my JSON". The reason I use XML examples (with profiles implemented as DTDs, XSDs and RELAXNGs) is simply that I don't know enough about the capabilities of JSON Schema.

sorry for being a broken record, but just to make sure we keep the eye on the prize: XML and DTD/XSD/RELAXNG do not have the same relationship as media types and profiles. DTD/XSD/RELAXNG are vocabularies (defined in specific schema languages) based on a specific metamodel (and as you pointed out, just getting any XML isn't going to cut it if you depend on a specific vocabulary being used). profiles are constraints on vocabularies (constraining/extending them) and you always get the same vocabulary, with or without profile. the profile is just a "style" of using it.

[larsgsvensson]

On 2017-04-25 14:34, Ruben Verborgh wrote: Yes, that's what we aim to do.

i sense a disconnect between what you're saying and what lars is talking about. maybe it would be good to clarify how this mechanism is supposed to be useful and to work on the web in general.

My vision is that profile negotiation works just as negotiation on mediatype (Accept / Content-type) or language (Accept-Language / Content-Language). If we assume (and that's a large if, just to show how I intended this to work) that the profile content negotiation is made using the Accept-Profile and Profile headers (analog to Accept-Language and Language) the interaction would be along those lines:

GET /some/resource
Accept: application/xml, text/xml
Accept-Language: en;q=0.8, fr;q=0.7
Accept-Profile: <http://example.org/profile-1>;q=1.0, <http://example.org/profile-2>;q=0.7

HTTP/1.1 200 OK
Content-Type: text/xml
Content-Language: fr
Profile: <urn:example:profile-2>

Here, <http://example.org/profile-1> and <http://example.org/profile-2> are profiles that can be implemented using different schemas (DTD, XSD, SHACL, DCMI Application Profile, ...). Originally, I intended those profiles to be applicable to specific media types but having the profile as an abstract model that has specific implementations in specific schema languages is fine, too, as long as we can get from the profile to the schema.

[larsgsvensson]

sorry for being a broken record, but just to make sure we keep the eye on the prize: XML and DTD/XSD/RELAXNG do not have the same relationship as media types and profiles. DTD/XSD/RELAXNG are vocabularies (defined in specific schema languages) based on a specific metamodel (and as you pointed out, just getting any XML isn't going to cut it if you depend on a specific vocabulary being used). profiles are constraints on vocabularies (constraining/extending them) and you always get the same vocabulary, with or without profile. the profile is just a "style" of using it.

What I hear is that my suggestion is more tied to what you call "schema" than to "profile". Is that correct?

[dret]

On 2017-04-25 16:30, Lars G. Svensson wrote:

sorry for being a broken record, but just to make sure we keep the
eye on the prize: XML and DTD/XSD/RELAXNG do not have the same
relationship as media types and profiles. DTD/XSD/RELAXNG are
vocabularies (defined in specific schema languages) based on a
specific metamodel (and as you pointed out, just getting any XML
isn't going to cut it if you depend on a specific vocabulary being
used). profiles are constraints on vocabularies
(constraining/extending them) and you always get the same
vocabulary, with or without profile. the profile is just a "style"
of using it.

What I hear is that my suggestion is more tied to what you call "schema" than to "profile". Is that correct?

probably. i think "vocabulary" might be a bit more neutral term because it is less tied to the implementation nature of a schema.

what i am wondering: apart from RDF, do you see use cases (by which i mean actual problems perceived in running systems)? i have never encountered anybody who wanted this two-level approach of being able to say "i want JSON, and i also want this vocabulary", or "i want XML, and i also want this vocabulary".

either people use specific media types to do this if they feel the need, or they use generic media types and are content that their APIs happen to use certain vocabularies, and that's an implicit coupling they're willing to accept.

if people care about content negotiation, they seem to be content to do it on the media type level. once again, either they negotiate on specific media types, or on the generic ones and then the vocabulary is implicit in the API.

i guess the only use case i can come up with if people wanted to negotiate on both levels:

• their API supports various metamodels such as XML and JSON.
• they also support various vocabularies in each of these metamodels.

i have never seen anybody asking for this when they designed an API.

[dret]

On 2017-04-25 16:29, Lars G. Svensson wrote:

Originally, I intended those profiles to be applicable to specific media types but having the profile as an abstract model that has specific implementations in specific schema languages is fine, too,

profiles make no statement about the fact whether they are tied to one specific media type or schema, or not. that's something that the people minting the profile URI can decide.

as long as we can get from the profile to the schema.

not in any way supported by the profile spec. and as discussed earlier, profiles are not necessarily implemented by a schema. they may be defined in prose, for example. and that's fine, too.

[hvdsomp]

On Tue, Apr 25, 2017 at 5:39 PM, Erik Wilde notifications@github.com wrote:

what i am wondering: apart from RDF, do you see use cases (by which i mean actual problems perceived in running systems)? i have never encountered anybody who wanted this two-level approach of being able to say "i want JSON, and i also want this vocabulary", or "i want XML, and i also want this vocabulary".

This is actually extremely common in applications in the realm of digital libraries, scholarly communication, cultural heritage where a wide variety of widely used XML-based metadata vocabularies exist to describe resources. AFAIK, these typically don't have dedicated MIME types; they just use the generic application/xml. The need to request a specific vocabulary is so prominent that the OAI Protocol for Metadata Harvesting, spec-ed between 2000 and 2002, and still extremely widely used today, has a request parameter to express the metadata vocabulary that a client desires. See e.g. http://www.openarchives.org/OAI/openarchivesprotocol.html#GetRecord.

Cheers

Herbert

either people use specific media types to do this if they feel the need, or they use generic media types and are content that their APIs happen to use certain vocabularies, and that's an implicit coupling they're willing to accept.

if people care about content negotiation, they seem to be content to do it on the media type level. once again, either they negotiate on specific media types, or on the generic ones and then the vocabulary is implicit in the API.

i guess the only use case i can come up with if people wanted to negotiate on both levels:

• their API supports various metamodels such as XML and JSON.
• they also support various vocabularies in each of these metamodels.

i have never seen anybody asking for this when they designed an API.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProfileNegotiation/I-D-Accept--Schema/issues/11#issuecomment-297071539, or mute the thread https://github.com/notifications/unsubscribe-auth/ADojAz9z__V2sEhF7aBy6eU6JLvsaWsAks5rzhOdgaJpZM4M913D .

-- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ http://orcid.org/0000-0002-0715-6126

==

[larsgsvensson]

i guess the only use case i can come up with if people wanted to negotiate on both levels:

• their API supports various metamodels such as XML and JSON.
• they also support various vocabularies in each of these metamodels. i have never seen anybody asking for this when they designed an API.

I think (but I'm not quite sure) that the use case that @dvh submitted yesterday (cf #17) goes in this direction. The spatial data is available in several formats (including GML (application/gml+xml) and RDF) and the customer can choose if they want the coordinates in EPSG:28992 (the Dutch reference system), in EPSG:4668 (the European reference system) or plain old CRS84 aka EPSG:4326. Is that correct, Dimitri?

A side note: GML is available in different flavours (that they call "profiles" as opposed to "application schemas"), too, cf. https://en.wikipedia.org/wiki/Geography_Markup_Language#Profile

[larsgsvensson]

what i am wondering: apart from RDF

OK, my original use case comes from RDF and that's where I have an itch to scratch. In the DNB, we have (for historical reasons) two services publishing data about the same authority entities (people, places and things). One is a "traditional" linked data service (LDS) using content negotiation to serve html, turtle and further RDF serialisations. The canonical URIs we mint for our entities resolve to this service and all RDF serialisations it offers use the same data model. The other service (EntityFacts) offers a beefed up version of the same data, enriched with images, further links etc. and originally only served JSON that later was made to JSON-LD. The URIs (really URLs) and the content model of EntityFacts are different from that of LDS. We also have a similar issue with two bibliographic formats (DINI-KIM and BIBFRAME), so it isn't specific to just one type of data.

Since we want to use the LDS URIs as the entry point to all our services, the goal is to integrate EntityFacts into the LDS. That would, however, mean that we need a way for the client to specify if they want the LDS format or the EntityFacts format (or profile, or schema, or whatever). That's why I wrote this spec and yes, it was heavily geared towards that use case. Then I got the feedback that the spec shouldn't be too geared towards RDF so I started to make it more abstract. And as Herbert wrote, there are non-RDF use cases for this from the cultural heritage domain.

[larsgsvensson]

as long as we can get from the profile to the schema.

not in any way supported by the profile spec. and as discussed earlier, profiles are not necessarily implemented by a schema. they may be defined in prose, for example. and that's fine, too.

Yes, profiles defined in prose are fine. But to perform validation or build interfaces (e. g. Java XMLBeans) we need an actual schema, too. That means that we need a way to get from the profile to the schema. If that's not part of the profile spec then we need another solution.

[dret]

On 2017-04-25 20:03, Lars G. Svensson wrote:

Yes, profiles defined in prose are fine. But to perform validation or build interfaces (e. g. Java XMLBeans) we need an actual schema, too.

why is that? if a profile is defined in prose that's what you have. you'll have to write code implementing that prose. you might prefer to have a schema and if you have the energy and skills you could write one yourself, but that doesn't change the fact that the profile is not defined by a schema.

That means that we need a way to get from the profile to the schema. If that's not part of the profile spec then we need another solution.

i think assuming that profiles always have one authoritative schema associated with them is not an assumption backed by how things work in practice. profiles have to be identifiable. that's it.

[larsgsvensson]

On 2017-04-25 20:03, Lars G. Svensson wrote: Yes, profiles defined in prose are fine. But to perform validation or build interfaces (e. g. Java XMLBeans) we need an actual schema, too. why is that? if a profile is defined in prose that's what you have. you'll have to write code implementing that prose. you might prefer to have a schema and if you have the energy and skills you could write one yourself, but that doesn't change the fact that the profile is not defined by a schema.

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.

That means that we need a way to get from the profile to the schema. If that's not part of the profile spec then we need another solution.

i think assuming that profiles always have one authoritative schema associated with them is not an assumption backed by how things work in practice. profiles have to be identifiable. that's it.

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:

Link: <http://example.org/someProfile/schema1.xsd>; rel="schema"; type="application/xml",
    <http://example.org/someProfile/schema1.rng>; rel="schema"; type="application/xml",
    <http://example.org/someProfile/schema2.ttl>; rel="schema"; type="text/turtle",
    <http://example.org/someProfile/schema2.jsonld>; rel="schema"; type="application/ld+json"

(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)). So what I'm trying to say is that we need a standardised mechanism to go from a profile document to associated schemas. A document talking about how to use that would then say something like "Profile publishers MAY want to link from their profile documents to associated schemas. If they do so, they SHOULD use the standardised mechanism". So I'm not saying that everyone has to do that. I'm only saying that we if someone wants to do that, we should give guidance on how to do that.

[dret]

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

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!

http://webconcepts.info/concepts/profile-uri/

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.

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

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.

So what I'm trying to say is that we need a standardised mechanism to go from a profile document to associated schemas. A document talking about how to use that would then say something like "Profile publishers MAY want to link from their profile documents to associated schemas. If they do so, they SHOULD use the standardised mechanism". So I'm not saying that everyone has to do that. I'm only saying that we if someone wants to do that, we should give guidance on how to do that.

as a starting point you're assuming that (a) you can find a "profile document" given a profile URI, and (b) there is such a thing as "a profile document". both of these assumptions are not true given the current state of things.

[dvh]

@larsgsvensson wrote:

I think (but I'm not quite sure) that the use case that @dvh submitted yesterday (cf #17) goes in this direction. The spatial data is available in several formats (including GML (application/gml+xml) and RDF) and the customer can choose if they want the coordinates in EPSG:28992 (the Dutch reference system), in EPSG:4668 (the European reference system) or plain old CRS84 aka EPSG:4326. Is that correct, Dimitri?

Yes, that's correct, except right now the spatial data is only available in JSON (as embedded GeoJSON). However for the statement of @dret:

• they also support various vocabularies in each of these metamodels. i have never seen anybody asking for this when they designed an API.

I don't think CRS negotiation has anything to do with a vocabulary. I just want to tell the server which CRS I prefer, just like using the Accept-Language to tell the server which language I prefer, apart from the mime-type returned.

[dret]

On 2017-04-26 12:08, Dimitri van Hees wrote:

I don't think CRS negotiation has anything to do with a vocabulary. I just want to tell the server which CRS I prefer, just like using the |Accept-Language| to tell the server which language I prefer, apart from the mime-type returned.

• brief detour but because this issue is dear to my heart: *

please keep in mind that in the recent RFC for GeoJSON CRS selection has been removed; only WGS84 is supported. the reason for this is exactly what we've been discussing in this issue (and what GeoJSON has experienced as painful interop issues before the RFC was published): CRS is not a profile-like thing because using different CRS means complete incompatibility at the very basic level of GeoJSON.

https://tools.ietf.org/html/rfc7946#section-4