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

Re: Beginning Guidance deliverable

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Wed, 23 May 2018 08:34:06 +0200
To: public-dxwg-wg@w3.org
Message-ID: <9ebcaaab-56cf-a64c-3b71-02911d938ba7@kcoyle.net>
In the past (I believe at F2F2) we had a brief discussion about the need
for a language for profiles (that would include constraints). The
general reaction was that this could end up being a language for
arbitrary metadata vocabularies, something we are not prepared to take
on. I'm not sure what the mechanism is, but we might be able to find a
place to note this need, as it could be something that W3C might see fit
to address in the future.

kc

On 5/22/18 11:07 PM, Rob Atkinson wrote:
> 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
> <mailto: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/Public/public-dxwg-wg/2018May/0144.html
>     <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> <mailto: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>>
>              > <mailto: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#>>
>              >   
>          <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>>
>              >   
>          <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>>
>              >   
>          <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>>
>              >   
>          <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>>
>         <mailto: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>
>         <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 http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600
Received on Wednesday, 23 May 2018 06:34:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:59 UTC