- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 23 May 2018 08:34:06 +0200
- To: public-dxwg-wg@w3.org
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