- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 15 Sep 2018 12:14:30 +0200
- To: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Forwarding to the public list for the record. I'll reply to that. - kc
-------- Forwarded Message --------
Subject: Re: ProfDesc representation of a DCAP
Date: Sat, 15 Sep 2018 09:23:01 +0000
From: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au>
To: Rob Atkinson <rob@metalinkage.com.au>
CC: kcoyle@kcoyle.net <kcoyle@kcoyle.net>, pedro.win.stan@gmail.com
<pedro.win.stan@gmail.com>
> All the DCAT profiles _exhibit_ inheritance hierarchies, but they are
> only expressed in text in documents... there has been no (obvious) way
> to express these hiearchies in axioms until now. So i dont think we
> need new UC at all - just to correctly interpret the ones we have.
>
>
>
>
>
> On Sat, 15 Sep 2018 at 09:11 Karen Coyle <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
>
> Nick, I think this thread should be available on the group's public
> list. Do you mind if I forward the emails to that? They are
> relevant to
> the work of the group.
>
> kc
>
> On 9/4/18 3:37 AM, Car, Nicholas (L&W, Dutton Park) wrote:
> > Hi Karen,
> >
> > I agree with your assessment of one DCAP/profDesc difference
> being that in DCAP, "There are no assumptions about the
> implementation context because those contexts are specific to each
> user and a DCAP should be usable and re-usable in whatever context
> people have." So then one profDesc, or similar system that does
> address context's value proposition, is that addressing that
> context is possible and useful. For example, it may be useful to
> say I have this DCAP defining rules in the "DSP abstract syntax"
> (I mean a syntax, like DSP, that is not system-specific or, in
> this case, executable) and it is contextualised in SHACL here,
> Schematron there, etc. . As a modelling pattern, we would then
> just say that the DCAP is a resource (of an identifying-only
> Profile object) with the "Guidance" role and the contextualised
> implementations are resources with "Full Constraints" or perhaps
> "Executable Constraints" roles. This then works well with current
> DCAP + contexts.
> >
> > Another thing profDesc is doing that DCAP (or ADMS or DCAT) is
> not doing is dependency. In profDesc, this Profile is a
> *profileOf* that Profile (or Standard) or set thereof. And, of
> course, this is transitive so, imagining (the not likely
> secenario) that I wanted to make the CSIRO ePub Repo use DCAT-AP
> info, then I would have:
> >
> > CSIRO ePub Repo Profile (is defined as a DCAP, implemented in
> SHACL, ShEx etc) profileOf [FOAF, DC, DCAT-AP]
> >
> > Perhaps FOAF is a Base Specification
> >
> > DCAT-AP profileOf DCAT
> >
> > So here now we are using DCAP but describing both
> implementations with context and dependency/derivation using
> profileDesc.
> >
> > Cheers,
> >
> > Nick
> >
> >
> >
> >
> >> OK, so if one produced a English written form of the DCAP as
> well as
> >> the DSP abstract syntax
> >
> > By DSP abstract syntax you mean the DSP document or DSP as
> implemented?
> > I never really know what people mean by "abstract syntax" since
> it seems to be used in various ways.
> >
> >
> >
> > so if you expressed the same profile in XML, in RDF, in
> SHACL.ttl, then I think we'd have three different DCAPs. But I'll
> try to chat with some other DCMI folks to see how they think of
> it. But there's no difference intended between a DCAP and
> something that can be implemented. The DCAP is the thing that can
> be implemented.
> >
> >
> > I think one of the differences between DCAP and profDesc is that
> DCAP does not attempt to define an implementation context.
> >
> > There are no assumptions about the implementation context
> because those contexts are specific to each user and a DCAP should
> be usable and re-usable in whatever context people have.
> >
> > -----Original Message-----
> > From: Karen Coyle <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
> > Sent: Tuesday, 4 September 2018 2:03 AM
> > To: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au
> <mailto:Nicholas.Car@csiro.au>>
> > Cc: Rob Atkinson <rob@metalinkage.com.au
> <mailto:rob@metalinkage.com.au>>
> > Subject: Re: ProfDesc representation of a DCAP
> >
> >
> >
> > On 9/2/18 8:37 PM, Car, Nicholas (L&W, Dutton Park) wrote:
> >> Hi Karen,
> >>
> >> Thanks for the example. If I try and characterise that one as
> well as you in parallel, let's see what we come up with independently!
> >>
> >> Those are good points you raised and I've spent some time both
> answering them below and also making up further dummy resources to
> demonstrate the answers.
> >>
> >>
> >>> A DCAP is not a profile of dublin core but of one or more
> vocabularies...
> >> Right you are! Since I used but DC, FOAF & others I've change to:
> >>
> >> " This is a dummy profile of a set of vocabularies (Dublin Core
> Terms, FOAF principally but those they utilise and others too)
> constructed as a Dublin Core Application Profile." In the README file.
> >>
> >
> > The statement "A profile is a named set of constraints on one or
> more identified base specifications," would define DCAP. Other
> than the decision rules (that are only human-executable),
> everything else is intended to be internal to the DCAP. It is
> described as a document only because XML (and SHACL) call their
> files "documents". "Document" does not imply something like PDF.
> >
> >>
> >>> The constraints are in the DCAP. In fact the role of the DCAP
> is primarily constraints. So there's no separate constraints document.
> >
> > Right, sort of. DCAP includes constraints, but also has
> definitions and human-readable instructions. (That latter was less
> evident in the original DCAP but is getting more emphasis in the
> version I am working
> > on.) All alone, it defines a metadata vocabulary and how it is
> implemented.
> >
> >> OK, so if one produced a English written form of the DCAP as
> well as
> >> the DSP abstract syntax
> >
> > By DSP abstract syntax you mean the DSP document or DSP as
> implemented?
> > I never really know what people mean by "abstract syntax" since
> it seems to be used in various ways.
> >
> > and also an RDF version of the DSP (the last two I have for the
> dummy) then the *theoretical* profile is the DCAP and then the
> written guidance, DSP abstract syntax & RDF versions are what
> profDesc calls "Profile Implementation Resources".
> >
> > No, that's not how it was seen. The DCAP is the implementation
> resource to be implemented. An RDF version would just be another
> DCAP. At the time there was no thought to having a DCAP in
> multiple serializations, so if you expressed the same profile in
> XML, in RDF, in SHACL.ttl, then I think we'd have three different
> DCAPs. But I'll try to chat with some other DCMI folks to see how
> they think of it. But there's no difference intended between a
> DCAP and something that can be implemented. The DCAP is the thing
> that can be implemented.
> >
> > The concept - implementation independent, including the written
> English
> > - is the profDesc "Implementation Profile" class object used to
> unite the multiple (3 in this e.g.) "Profile Implementation
> Resource" objects.
> >
> > see above
> >
> >>
> >> I've added a dummy PDF "Profile Implementation Resource" to the
> repo to round out the three. Here now the profDesc "Profile"
> object is the total repo containing all the three "Profile
> Implementation Resource" files. I've indicated a so-far
> non-functioning URI for the dataset of
> http://linked.data.gov.au/dataset/CSIRO-ePub-DCAP which would be
> the URI of the "Implementation Profile" object. I'll make this
> function when it looks like we've reached agreement on all these
> parts to allow people to dereference all the Profile and Resource
> URIs.
> >
> > I'll try to get a look at that. Currently packing to be away
> from home for 2 months.
> >
> >>
> >> In the Aust. Govt. Linked Data WG it looks like we will need to
> mint URIs for profiles in addition to datasets, ontologies, vocabs
> and Linked Data registers. The issue now is what form should they
> take? Are profiles definitional resources like ontologies thus we
> should use .../def/... rather than .../dataset/... as I've done in
> this example? I think so. If sensible I'll update this example to
> use /def/.
> >>
> >>
> >>> I don't know what the difference is between profile guidance
> and guidance. There is only one guidance concept in DCAP.
> >> In the vocab associated with profDesc
> (https://w3c.github.io/dxwg/profiledesc/impl_res_roles.html),
> there are several roles that "Implementation Resource Descriptors"
> may play defined. The Guidance one ("Guidance notes of a profile")
> would be the document form in English or similar whereas others
> look more technical and for validation such as FullConstraints:
> "Constraints specifying a conformance test". The different roles
> then let you differentiate between resources as I have done with
> the roles for the CSIRO ePublish dummy. There, we have the
> Guidance PDF (now added to the repo at
> https://github.com/CSIRO-enviro-informatics/csiro-epub-dcap) and
> the FullConstraints in both DSP syntax and RDF. If another
> implementation of FullConstraints in SHACL was made, these would
> allow for instance validating with existing tooling - the existing
> SHACL validators.
> >
> > The DCAP concept was/is that the DCAP has both technical
> constraints and human-readable guidance. If you look at DCAT-AP
> you see that it has both, albeit in a text document form. But a
> single underlying technical file could contain both technical
> constraints and human guidance, and could be used to generate
> human-readable documentation as well as conformance code. Those
> human-readable documents and the code that implements the
> validation (e.g. TopBraid) are outside of the DCMI purview and are
> purposely not addressed.
> >
> > I think one of the differences between DCAP and profDesc is that
> DCAP does not attempt to define an implementation context. How the
> DCAP is implemented and in what system context it resides is not
> part of DCAP.
> > You seem to have a system context in which you are working, so
> you are filling in elements, like the implementation resources,
> that DCAP consciously did not define, because it is intended to be
> supported by whatever context people have. Whether someone uses a
> DCAP to derive a SHACL document, or whether they extract the
> human-readable elements into a document that looks something like
> DCAT-AP is up to them. There are no assumptions about the
> implementation context because those contexts are specific to each
> user and a DCAP should be usable and re-usable in whatever context
> people have.
> >
> > kc
> >
> >>
> >> Apart from allowing a single profile concept (realised as a
> instance) to join multiple implementations, including such
> possibilities in profDesc allows for the capture of more and less
> formally defined profiles (just a descriptive, Guidance, doc v. a
> formal DSP/SHACL-style constraint set) that we know exist.
> >>
> >> Thanks for the DTD. I'll try and work out how this ties in.
> >>
> >> Nick
> >>
> >>
> >>
> >> On 3/9/18, 1:10 am, "Karen Coyle" <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
> >>
> >> I did find one DCAP that was done experimentally,
> SWAP.[1][2] As for
> >> your diagram, this is hard to do in words so I may have to
> scribble one
> >> myself but that'll happen later as I'm soon off to more
> cultural
> >> endeavors, but...
> >>
> >> A DCAP is not a profile of dublin core but of one or more
> vocabularies,
> >> so I'd remove DC and have a set of vocabs, A, B, C. It's
> intended to be
> >> unrelated to the DC metadata.
> >>
> >> The constraints are in the DCAP. In fact the role of the
> DCAP is
> >> primarily constraints. So there's no separate constraints
> document.
> >>
> >> I don't know what the difference is between profile
> guidance and
> >> guidance. There is only one guidance concept in DCAP.
> >>
> >> I don't know what an implementation profile is. Again, the
> DCAP,
> >> conceptually, is input to an implementation. It would be
> very similar to
> >> a SHACL or ShEx document, but with a user-facing function
> included.
> >>
> >> I found the DSP DTD (it was conceived as XML - it was a
> while ago) and
> >> am attaching it.
> >>
> >> kc
> >> [1]
> http://dublincore.org/usage/reviews/2009/swap/snapshot/index.html
> >> [2] http://www.ukoln.ac.uk/repositories/digirep/index/SWAP
> (who knows if
> >> the links work, since ukoln has been disbanded, I think)
> >>
> >> On 9/2/18 6:14 AM, Car, Nicholas (L&W, Dutton Park) wrote:
> >> > Hi Karen,
> >> >
> >> > I know about DSP but it's instance of their use I'm after.
> >> >
> >> > OK, to test out my understanding I've made up a dummy
> instance, see
> https://github.com/CSIRO-enviro-informatics/csiro-epub-dcap. No
> doubt my DSP constraints are full of errors but its the relations
> of the resources, as described using ProfDesc, that's the thing
> that's being tested here.
> >> >
> >> > If this dummy looks sensible to you I'll add it to the
> profileDesc examples.
> >> >
> >> > It was interesting trying to fully digest the DSP syntax
> & logic. I haven't yet had a chance to look at your v2 but I'll
> give that a go soon. And then also perhaps a re-implementation of
> the DSP rules in SHACL, just for comparison.
> >> >
> >> > Cheers,
> >> >
> >> > Nick
> >> >
> >> >
> >> >
> >> > On 2/9/18, 2:27 am, "Karen Coyle" <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
> >> >
> >> > Nick, there isn't a "live" DCAP - it never was
> implemented in code. You
> >> > can base your work on the DSP[1] and if I can find it
> I will send you
> >> > the XML for that. However it's very out of date.
> >> >
> >> > I began a new attempt at a new DCAP[2] but it's crude
> still and DCMI
> >> > hasn't yet convened a group to work on it. It has the
> same structure as
> >> > DSP but eschews the terminology of the DC Abstract
> Model which, while
> >> > potentially informative, never caught on, perhaps due
> to the use of
> >> > rather difficult terminology.
> >> >
> >> > kc
> >> >
> >> > [1] http://dublincore.org/documents/dc-dsp/
> >> > [2] https://github.com/kcoyle/RDF-AP
> >> >
> >> > On 8/31/18 6:23 PM, Car, Nicholas (L&W, Dutton Park)
> wrote:
> >> > > Hi Karen,
> >> > >
> >> > >
> >> > >
> >> > > I’d like to try out the expressive power of
> ProfileDesc by representing
> >> > > an instance of a DCAP using it, as we’ve done with
> DCAT-AP. I think also
> >> > > representing DCAP things using it will better
> communicate what
> >> > > ProfileDesc does vis a vis a the DC systems like
> DSPs etc. I’d add the
> >> > > characterisation to the ProfDesc examples.
> >> > >
> >> > >
> >> > >
> >> > > Reading
> http://dublincore.org/documents/profile-guidelines/ I understand
> >> > > the model but I have no instances to work with! Can
> you please:
> >> > >
> >> > >
> >> > >
> >> > > * Indicate an (preferably in use) example of a
> DCAP so I can find all
> >> > > the likely relevant ProfDesc elements and
> characterise them
> >> > >
> >> > >
> >> > >
> >> > > If I understand things correctly, I think I see the
> following
> >> > > characterisation (ProfDesc classes in bold,
> properties in italics):
> >> > >
> >> > >
> >> > >
> >> > > *Base Specification*(being profiled): DC
> >> > >
> >> > > *Implementation Profile*: an example you can
> hopefully send me
> >> > >
> >> > > *Implementation Resource Descriptor*: a DSP
> instance for the profile
> >> > >
> >> > > * /resourceRole/: Complete set of constraints
> >> > >
> (https://w3c.github.io/dxwg/profiledesc/impl_res_roles.ttl#FullConstraints)
> >> > >
> >> > > * /dct:format/: application/xml (or by URI
> >> > > https://w3id.org/mediatype/application/xml) //
> >> > > * /dct:conformsTo/: DSP specification (using DC
> identifier
> >> > >
> http://dublincore.org/documents/2008/03/31/dc-dsp/)//
> >> > >
> >> > > Another *Implementation Resource Descriptor*: any
> resources about the
> >> > > DCAP that act as guidance (rather than constraints)
> such as a PDF
> >> > >
> >> > > * /resourceRole/: Guidance notes of profile
> >> > >
> (https://w3c.github.io/dxwg/profiledesc/impl_res_roles.ttl#Guidance)
> >> > > * /dct:format/: application/pdf (or similar) (or
> by URI
> >> > > https://w3id.org/mediatype/application/pdf, or
> similar) //
> >> > >
> >> > >
> >> > >
> >> > > Does this look sensible? Are there things you think
> are important to
> >> > > know about a specific DCAP that are not represented
> by ProfDesc here? If
> >> > > so, we’d be keen to extend it to capture things of
> real importance to
> >> > > profiling communities.
> >> > >
> >> > >
> >> > >
> >> > > By the way, an interesting exercise might be to
> create another
> >> > > constraints Implementation Resource Descriptor for
> the profile using
> >> > > SHACL which could operate on an RDF document
> claiming adherence to the
> >> > > DCAP instance. This would further indicate the
> separation of concerns
> >> > > between constraints, guidance and overall profiling
> description.
> >> > >
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> > >
> >> > >
> >> > > Nick
> >> > >
> >> > >
> >> > >
> >> >
> >> > --
> >> > Karen Coyle
> >> > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
> http://kcoyle.net
> >> > m: 1-510-435-8234 (Signal)
> >> > skype: kcoylenet/+1-510-984-3600 <tel:+1%20510-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 <tel:+1%20510-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 <tel:+1%20510-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 <tel:+1%20510-984-3600>
>
Received on Saturday, 15 September 2018 10:15:00 UTC