W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > May 2018

Re: Beginning Guidance deliverable

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Wed, 23 May 2018 07:07:16 +1000
Message-ID: <CACfF9Lxzoh-TNsGKiNhx8=3ueQpi0ULUO=M5BLhUf44FwD9bvA@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: Dataset Exchange Working Group <public-dxwg-wg@w3.org>
fully agree.

It sounds like there is quite a pent-up demand for a good constraint
language - maybe an extension of SHACL or SHex - but this is a huge amount
of work and I think we would need some working examples and a solid
proposal before we could take it on inside a WG.




On 23 May 2018 at 05:52, Antoine Isaac <aisaac@few.vu.nl> wrote:

> 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/P
> ublic/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-Gks5
>> dDa8n2B5IN6rWa3kRpo/edit# <https://docs.google.com/docum
>> ent/d/15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/edit#>
>>      >     <https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gk
>> s5dDa8n2B5IN6rWa3kRpo/edit# <https://docs.google.com/docum
>> ent/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-Gks5
>> dDa8n2B5IN6rWa3kRpo/edit#heading=h.bm0x3wnhiwa1 <
>> https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks
>> 5dDa8n2B5IN6rWa3kRpo/edit#heading=h.bm0x3wnhiwa1>
>>      >     <https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gk
>> s5dDa8n2B5IN6rWa3kRpo/edit#heading=h.bm0x3wnhiwa1 <
>> https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks
>> 5dDa8n2B5IN6rWa3kRpo/edit#heading=h.bm0x3wnhiwa1>>
>>      >     [2]
>>      > https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks5
>> dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413 <
>> https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks
>> 5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413>
>>      >     <https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gk
>> s5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413 <
>> https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks
>> 5dDa8n2B5IN6rWa3kRpo/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 21:08:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 25 March 2019 10:33:23 UTC