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

Fwd: ProfDesc representation of a DCAP

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>
Message-ID: <1ebe0182-93f3-8f60-a412-78cf2f0d1cb9@kcoyle.net>
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

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