Re: Beginning Guidance deliverable

 @andrea

Neat summary - that is all correct.

I think the implication is that profiles may define constraints over
multiple standards (DCAT, ADMS, VOAF... etc)  - and we could define a
profile of profileDesc for DCAT profile best practices. This profile may
also be a profile of the other vocabularies - if use of the properties from
them entail object Type.  I dont think it is a profile of RDFS is we just
use an annotation property like rdfs:label, but if we entail a object type
perhaps it is.  I think that in the OWA we don't need to declare these
relationships however, we can just declare the DCAT inheritance if we want.

finally - what constrain language is going to allow us to specify use of
external vocabularies (thats a BP not a profileDesc problem, but it might
need a special prof:resourceRole  ? )

@kcoyle: I think you are correct in that we have not adequately expressed
the DCAT-AP use case, with its inheritance patterns used in practice as a
separate UC.  It is explicit elsewhere, (UC5.3), and maybe its easy to
switch off when we see the profile negotiation context, but to a data
modeller its kind of implicit everywhere, and Makx's recent presentation
really highlighted it as the basis for application of DCAT-AP use in
practice.  We could capture this better IMHO.

Requirement 6.8.2 "RPFRP" starts off with the requirement - and these
cannot be met be existing ad-hoc documentation of profiles (PDF,
schematron, word docs, etc, nor SHACL ans SHex as far as i can tell)

   1. Machine-readable specifications of application profiles need to be
   easily publishable, and optimize re-use of existing specifications.
   2. Application profiles need a rich expression for the validation of
   metadata
   3. Profiles must have properties for at least two levels of
   documentation: 1) short definition 2) input and editing guidance
   4. Profiles must support declaration of vocabulary constraints
   5. A mechanism must be available to identify conformance to each
   inherited profile given conformance to a profile that specialises it.

(#2 points towards SHACL etc, but the other aspects motivate profileDesc)

NB - what is missing in the UCR is the link back from this requirment to UC
"5.3 Responses can conform to multiple, modular profiles [ID3]"





On 11 May 2018 at 16:38, Karen Coyle <kcoyle@kcoyle.net> wrote:

>
>
> On 5/10/18 11:53 PM, Rob Atkinson wrote:
> > I would suggest that the Guidance should say that profiles need to be
> > described in a way that meets requirements X,Y,Z and that a suitable
> > vocabulary has been developed to provide a canonical means to do this in
> > the context of DCAT usage or other similar RDF implementations. Other
> > platforms may choose equivalent approaches, noting the more standardised
> > the profile description is the higher degree of interoperability that is
> > supported between the resources that conform to such profiles.
>
> Rob, as we discussed at the f2f, profileDesc allows one to connect all
> of the needed pieces, one of which is a profile. Our understanding was
> that profileDesc does not define the contents of a profile (vocabulary
> terms, constraints, dependencies, etc.). So we need to be very careful
> in our wording. I think that the "meets requirements" part will be
> instead expressed as a discussion of practices ("best-ish" but more
> like: if you do it this way then you get this functionality). Then we'll
> offer profileDesc as the "glue" between profiles and the datasets that
> they support.
>
> Note that at the moment we have NO use cases that would support
> profileDesc - all of the profile-related use cases instead speak to
> either the "best-ish practices" or content negotiation. It would appear
> that you and Nick have some actual use cases that fostered profileDesc
> and it would be good to have those in our UCR document.
>
> kc
>
> >
> > Basically, as W3C ontology (with as yet no obvious identified
> > alternatives) profiledesc would fit a general recommendation to use the
> > W3C canon where appropriate... whilst future work might offer a
> > different solution . We should aim to show it is fit-for-purpose for
> > typical use cases.  The guidance may have equivalent sections for
> > different aspects - e.g. around use of PROV, Datacube and other W3C we
> > want to recommend and demystify, but without enforcing in DCAT itself
> > for example.
> >
> >
> >
> >
> >
> > On 10 May 2018 at 21:09, Karen Coyle <kcoyle@kcoyle.net
> > <mailto:kcoyle@kcoyle.net>> wrote:
> >
> >     All,
> >
> >     As you may have understood from the previous report from F2F3, a
> major
> >     goal was to clarify the scope and contents of the Guidance document
> and
> >     create the necessary structure around the work so that we can begin
> to
> >     prepare a first public working draft.
> >
> >     Decisions and information were taken down during the meeting in a
> G-Doc:
> >
> >     https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-
> Gks5dDa8n2B5IN6rWa3kRpo/edit#
> >     <https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-
> Gks5dDa8n2B5IN6rWa3kRpo/edit#>
> >
> >     Actual work on the Guidance deliverable will probably be moved
> elsewhere
> >     as this G-Doc is quite sketchy, but I wish to point out that there
> are
> >     key sections on the Project Plan [1] and a beginning of an outline
> for
> >     the document [2].
> >
> >     At the meeting, Karen, Rob and Antoine volunteered to be editors on
> the
> >     document. Other editors are welcome, but do remember that everyone
> can
> >     contribute.
> >
> >     We need to have a full working group discussion of profileDesc, [3]
> >     which has so far been primarily the work of Rob and Nick, and make
> any
> >     changes necessary so that it reflects the consensus of the entire
> group.
> >     The current proposal is a first draft that has been offered to the
> group
> >     for discussion and modification.
> >
> >     Note that we have not yet concluded how to integrate the guidance
> aspect
> >     of the deliverable and the profileDesc ontology. The complication is
> >     that the guidance document may read much like "best practices" but
> >     profileDesc is an ontology. Tying them together in a recommendation
> >     creates a dependency for maintenance that could be problematic. While
> >     one could anticipate that profileDesc may be updated in the future
> after
> >     additional experience, the more general guidance content of the
> document
> >     may not need to change. Peter and I are soliciting advice from folks
> >     with more W3C experience to try to discover the best solution.
> >
> >     kc
> >
> >     [1]
> >     https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-
> Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.bm0x3wnhiwa1
> >     <https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-
> Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.bm0x3wnhiwa1>
> >     [2]
> >     https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-
> Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413
> >     <https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-
> Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413>
> >     [3] https://github.com/w3c/dxwg/tree/gh-pages/profiledesc
> >     <https://github.com/w3c/dxwg/tree/gh-pages/profiledesc>
> >     --
> >     Karen Coyle
> >     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
> >     m: 1-510-435-8234 (Signal)
> >     skype: kcoylenet/+1-510-984-3600
> >
> >
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600
>