Maybe I'm conflating things here.
 
Yes, my sentence "So yes, that means that many profiles that exist in the wild currently cannot be used for content negotiation on profile" should read "So yes, that means that many profiles that are sections or fragments of larger resources currently cannot be used for content negotiation on profile.
 
I'll try again:
 
1) In order for a profile to be used for content negotiation, it needs a (unique) URI.
2) If a profile is part of a larger document that contains several profile specifications, each of those profile specifications needs it's own URI (which would probably be a URI fragment). _Iff_ the larger document only contains one profile specification, it MIGHT be possible to use the document URI as a proxy for the profile URI for conneg purposes, but that feels a bit streched.
 
Regarding profile documents that don't have URIs can still be relevant for conneg by giving them a URI. Things like urn:isbn or urn:nbn come to mind... If the profile was defined in chapter seven of the book with ISBN 1-23-456-7 it would be (theoretically) possible to negotiate on urn:isbn:1-23-456-7#chapter-7 if the relevant community members agree on that profile URI.
 
Best,
 
Lars
 
Gesendet: Dienstag, 06. August 2019 um 18:33 Uhr
Von: "Karen Coyle" <kcoylenet@gmail.com>
An: lars.svensson@web.de
Cc: "Thomas Baker" <tom@tombaker.org>, public-dxwg-comments <public-dxwg-comments@w3.org>
Betreff: Re: Re: Comments on "Content Negotation by Profile" (30 April)
I'm confused by this conclusion: "So yes, that means that many profiles that exist in the wild currently cannot be used for content negotiation on profile."
 
The question, however, is about parts of documents: "In order to be able to use profiles specified as parts/sections of larger documents, those profiles/sections need their own URIs." Should the above sentence read instead: "... many profile sections or fragments that exist in the wild ..."? or "... many profiles that are sections or fragments of larger resources ..." Because a document that is a profile and that has a URI can be used for content negotiation, e.g. DCAT-AP in PDF form. True? It's just that sections within that document, if they cannot be accessed through a fragment URI, cannot.
 
I believe that the set of profile documents that do not have URIs, and therefore are not online, are outside of the scope of conneg. Are there any resources that meet the definition of profile and that have a URI that are outside the scope?
 
On Mon, Aug 5, 2019 at 12:50 AM <lars.svensson@web.de> wrote:
Dear Tom,

On Dienstag, 16. Juli 2019 um 11:49 Uhr lars.svensson@web.de scripsit:

> On Freitag, 12. Juli 2019 um 11:41 Uhr, Thomas Baker scripsit:
>
> > > > The CONNEG draft characterizes DCMI Metadata Terms
> > > > (DCMIMT) as a profile, where the definition of
> > > > "profile" distinguishes between profiles and base
> > > > specifications on which profiles are based.
> > >
> > > This issue is related to the problem of identifying
> > > profiles (and specifications) when embedded in
> > > documents with multiple sections or performing multiple
> > > roles, where clear identification of the conformance
> > > requirement is not available.
> >
> > The ODRL example looks fine, but does this mean that if
> > sections of those documents were not clearly defined, any
> > DCAT profile (or indeed most profiles that currently
> > exist in the wild) would not be suitable for content
> > negotiation as per CONNEG?
>
> That's a fair question and something we'll need to discuss.

On Thursday, August 1, the CNEG subgroup discussed your question about the identification of profiles that are embedded in documents [1]. Following the spirit of Issue #1017 [2], we resolved on the following:

In order to be able to use profiles specified as parts/sections of larger documents, those profiles/sections need their own URIs. Those URIs can be constructed as fragment of the URIs of their embodying specification URI or be independent thereof. If the profile does not have a URI of its own, it is not possible to perform content negotiaion for representations conforming to that profile.

So yes, that means that many profiles that exist in the wild currently cannot be used for content negotiation on profile. Communities are encouraged to use some (other) URI space to mint URIs for those profiles and refer back to the original specification through a textual note. E. g.

@prefix definitionUriSpace: <https://example.org/specs/>

profileUriSpace:profileOfSomeOtherSpecification a prof:Profile ;
    rdfs:label "Profile of Other Specification" ;
    dct:definition """This is a profile of the Other Specification as specified in
        'Insert Name of Your Specification Here'. Please refer to
        <https://example.org/specs/otherSpecification.pdf> §18.4 for the
        formal definition""" ;
    rdfs:seeAlso definitionUriSpace:otherSpecification.pdf .

Does this resolve your question?

[1] https://www.w3.org/2019/08/01-dxwgcneg-minutes#x04
[2] https://github.com/w3c/dxwg/issues/1017

Best,

Lars for the CNEG subgroup

ACTION-355

> > I always thought that the spirit of CONNEG was to be
> > liberal about may be used as a URI for content
> > negotiation (e.g., even purl.org/dc/terms/),
>
> From a conneg point of view, the profile URI can point to anything (including nothing, i. e. the profile URI can return 404).
>
> In the IETF document we say that _if_ the profile URI is a protocol URI (http/https/ftp/sftp/...) it SHOULD resolve to a resource with a profile description. This is something we need to make more explicit in the conneg document. A further possibility is to constrain this further and say that the profile URI SHOULD resolve to a profile description and that the server SHOULD use content negotiation (by profile) to serve the best available representation of the profile. The client can ask for a specific profile of the profile (e. g. a ShEx version) and then the server would return a ShEx document that can be used for validation. If the client does not specify any specific representation of the profile URI, the server can return any representation it wishes and in many cases that might be a PDF document with only human-readable information, but it can also be a profile description document using the PROF vocabulary so that the client can figure out which representations of the profile are available.
>
> That said, I agree that
>
> > requirements about the internal structure of profiles
> > would properly belong in best-practice guidelines --
> > not in CONNEG per se.
>
> Yes, that's outside of Conneg. Would be part of the profile guidance document, if that's written.
>
> > > The DCMI community may choose to consider "application
> > > profiles" to be exclusively profiles of its published
> > > specification(s) (vocabulary),
> >
> > I see why you would say this but need to clarify a point. 
> >
> > For many years, the Dublin Core community has broadly
> > used the term "Dublin Core application profile" to refer
> > not to a profile specifically of DCMI Metadata Terms, but
> > to a profile in the style that has emerged in the DC
> > community since 1999, of mixed-vocabulary profiles --
> > irrespective of whether DCMI metadata terms are even used
> > in the profile at all.  In other words, the DC concept of
> > profile is quite ecumenical and would include profiles
> > that consist entirely of terms from Schema.org or BIBFRAME.
>
> OK. Thank you for this clarification. Do you see any need for us to update the Conneg document with this information or would you say that it should be handled in Profile Guidance?
>
> [...]
>
> > > Agreed - the OpenGeospatial Consortium has a concept of
> > > "conformance target" for its specifications
> > ...
> > > :myProfile a dct:Standard, prof:Profile ;
> > >     prof:conformanceTarget my:ClassOfThingsThatConformToMyProfile .
> >
> > Okay... but surely this is in the realm of best practice
> > for profiles -- and outside of the scope of CONNEG?
>
> Yes, that's outsied of conneg.
>
> Thanks for your contribution!
>
> Best,
>
> Lars
 


--
--  ---
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
skype: kcoylenet
mo.: 510-435-8234
------------------------------------
https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Aug/att-0001/00-part
lists.w3.org
CC-MAIN-2024-26
12378
application/http; msgtype=response
sha1:KU7M3HRBAUVD2BXWJXI3RXL4S7F3SRLD
<urn:uuid:4ab0ee3a-755e-4a4b-91f1-613115e470a9>
2024-06-22T23:53:28Z
104.18.22.19
text/html
sha1:YAURWKWDXVD2JTB3TWPELCSOJVBNYKJW
<urn:uuid:a596e515-334f-4937-82bb-72bf04886f83>
https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Aug/att-0001/00-part
response
<urn:uuid:17425308-31e2-4e57-aa92-e4f806c8c976>
isPartOf: CC-MAIN-2024-26
publisher: Common Crawl
description: Wide crawl of the web for June 2024
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-80
software: Apache Nutch 1.20 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.5-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/