It appears to me that PROF is giving us profile modelling - out of scope for Conneg by P - but also hooks from profiles to resources that conform to them, viz `rdfs:Resource dct:conformsTo prof:Profile` and also a description of a `Resource`, viz. the `prof:ResourceDescriptor` class. Conneg by P seems to require (from our testing) that there is a `Representation` class, instances of which represent, as per the HTTP spec [[RDF7230](https://httpwg.org/specs/rfc7230.html)], "An abstraction of the current or desired state of a thing in HTTP communications.". It seems fairly obvious that we have something like this: ``` rdf:Resource conneg:hasRepresentation conneg:Representation . conneg:Representation dct:conformsTo prof:Profile . ``` So the tie-point question seems to be: * how does a `conneg:Representation` class fit into PROF, if at all? `conneg:Representation` is modelling implementations of data which will border PROF and PROF also contains: `prof:ResourceDescriptor prof:hasArtifact rdf:Resource` where the *artifact* is the realisation of the resource that is the thing conforming to a `prof:Profile`. We've not teased apart resources ans representations of them in PROF and this requirement from Conneg could be the thing that does that. -- GitHub Notification of comment by nicholascar Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1041#issuecomment-520285395 using your GitHub accountReceived on Monday, 12 August 2019 02:38:51 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:28:31 UTC