Re: Beginning Guidance deliverable

Hi all,

Apologies if I'm catching this thread late - I was basically unable to read mails in the past week. (Apologies if I'm repeating point that have already been made in discussions that I've not yet read)

I think Rob's answer for the requirements for ProfileDesc go a long way in justifying its position.
In particular, I see profileDesc as the tool to be used for creating the descriptions (in RDF or else) that need to be returned when the URI of a profile is to be de-refered (or content negotiated). As we discussed in F2F3, the glue that ties possible 'implementations' of a profile (in SHACL, XMLSchema or else), as well as its documentation.

About Andrea's distinction between 'profile description' and 'profile definition' at http://lists.w3.org/Archives/Public/public-dxwg-wg/2018May/0144.html I agree with the general principle but there are two points that make me feel hesitant.

1. I'm not keen on the terms 'definition'. First because it collides with our other efforts on 'profile definition' as "the definition of what 'profile' means". Second, because I expect a definition to be rather complete, and the various 'definitions' in Andrea's meaning won't be complete (an XML Schema for a profile is likely not to capture what a SHACL file will capture).
I would much prefer to try and adapt the parliance of web architecture and content negotiation. Things like an XML Schema, SHACL or ShEx for a profile are rather 'representations' of the profile in a specific language.

2. I'm not sure I fully understand the sentence "the profile description is likely to be RDF-centric, although it could be used to provide metadata about any type of profiles – not necessarily based on RDF." What I'm hoping it says is that the profile description may be expressed in non-RDF language. I.e. we should define profileDesc as a data model that has a serialization in RDF but not necessarily enforce RDF as its own serialization.

Cheers,

Antoine

On 14/05/18 00:28, Rob Atkinson wrote:
> @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 <mailto: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>
>      > <mailto: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#>
>      >     <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>
>      >     <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>
>      >     <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>
>      >     <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> <mailto: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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234 (Signal)
>     skype: kcoylenet/+1-510-984-3600
> 
>

Received on Tuesday, 22 May 2018 19:53:17 UTC