add RFC 6906 to profiles ontology

[dret]

in the newly published profiles ontology, it would be useful to reference RFC 6906 and to point out the differences. RFC 6906 has been around for a while and is in active use on the internet to indicate the presence of profiles.

[nicholascar]

This is more a matter for the Content Negotiation by Profile which deals with "how Internet clients may negotiate for content provided by servers" than it is for the Profiles Ontology which "is an RDF vocabulary to describe profiles", although all doc references, or lack of, merit investigation.

For reference: RFC 6906 “the ‘profile’ Link Relation Type”: https://tools.ietf.org/html/rfc6906

[dret]

On 2018-12-18 11:12, Nicholas Car wrote: This is more a matter for the Content Negotiation by Profile than it is for the Profiles Ontology...

is it? my comment was about referencing the fact that there are defined semantics for indicating profiles on the internet and the web, and that referencing those would be helpful. i am aware that RDF has technical issues with simply using existing link relations, but at least indicating that an RDF model is duplicating existing functionality would be good.

[aisaac]

I guess I agree with @nicholascar . It's not that the Profiles Ontology shouldn't be concerned. But it is rather a priority for the Conneg spec, which is more obviously in need to distinguish itself from RFC6906.
Then the way the matter is handled within the scope of the Conneg spec can be reflected in the Profile ontology. But that would be a second step.

[rob-metalinkage]

I tend to agree with @dret - I did in fact look at this when looking at the group's charter - and more recently at the description of profile in the IANA registry.

It didnt emerge as a motivating Use Case - however I thinks its probably reasonable we acknowledge it as a requirement that our further refinement of the notion of profiles is compatible with this - which I believe it is.

I see @nicholascar's point - the direct impact is on negotiation mechanisms, so if we ensure consistent use there then it follows that the profiles ontology is semantically compatible, but it IMHO doesnt hurt to make this more explicit in the profiles ontology.

[dret]

now that the conneg WD was published, i see the point. i think both documents should take existing standards into account, but that indeed may be more relevant for the conneg spec that specifically talks about links and HTTP and link header fields.

[larsgsvensson]

@dret Thanks for your feedback. So would it solve this issue if we added some text to §5 Related Work of the Conneg by AP guidance document?

My proposal would be:
[[
RFC 6906 defines the "profile" relation type for Link headers (RFC 8288). The profile relation allows source representations to indicate that they are following one or more profiles. The definition of a profile in RFC 6906 §3 is very similar to the one used here and also uses URIs for profile identification.
The use of a Link: rel="profile" <URI> header has a functions similar to the target attribute for the Link header suggested in §7.1.1.2 of the conneg-by-ap doc. The difference is that the use of rel="profile" links the source document directly to the profile(s) it follows (the target URI in the Link header is the URI of the profile), whereas the "profile" attribute in a Link header specifies the profile of the source document itself (when using rel="self") or an alternative representation of the source document (when using rel="alternate").
]]

[nicholascar]

@dret can you please comment on @rob-metalinkage's proposal above so we know if this will satisfy your request?

[dret]

On 2019-02-22 09:22, Nicholas Car wrote: @dret <https://github.com/dret> can you please comment on @rob-metalinkage <https://github.com/rob-metalinkage>'s proposal above so we know if this will satisfy your request?

my apologies for the delay. i think this is covered by #45 (comment) now which to me reads nicely balanced.