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