- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 15 Sep 2018 18:32:47 +0200
- To: public-dxwg-wg@w3.org
On 9/15/18 12:14 PM, Karen Coyle wrote:
>> 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.
I would propose that the DCMI view of profiles is one valid possibility
among many. However, it differs from what you state here in some
details, in particular in that there is no "+ contexts" required - the
profile is the value proposition.
In terms of "profile of ...", in DCAP this is not needed because the use
of IRIs reveals the base vocabularies. If something else is needed to
address that this is part of a "family" of profiles, that information
should be added to the profile vocabulary (the DSP) because it would be
needed regardless of who is making use of the metadata described in the
profile.
In terms of validation and implementation, the implementation
constraints themselves are to be encoded in the profile's (DSP)
language, rather than being a separate file or entity. (You may choose
to convert those to SHACL or Schematron, but they live natively in the
profile.)
DCAP does include guidance (notes for input, etc.) but is not limited to
guidance. It is intended to be "application-ready"; it *is* an
implementation resource. It is intended to not require (but not
preclude) additional information for its use.
Any information about the profile that is considered vital for use of
the profile should be included as part of the DCAP profile language. For
the purposes of portability and re-usability, it should be as
self-contained as possible.
The vision of DCAP is that a data provider and a data consumer can use
the same profile (a single document) to create and process the metadata
even if they are not operating within the same system and may not even
communicate directly with each other.
That has been the goal of DCAP, and some of us in the Dublin Core
community still think this is a goal to work toward. I believe that it
is conceptually different from the context provided by profileDesc
although hopefully not contradictory in any way. Because DCAP as
envisioned is a profile that includes the necessary implementation
information, it would (as I understand it) make minimal use of
profileDesc entities. I would hope that it would not be incompatible
with profileDesc, and that if an implementation used profileDesc, DCAP
could occupy the "profile" entity space without contradiction.
All of this presumes that at a future date something like the DSP
becomes a standard profile definition language, something which I feel
is somewhat overdue but there is a growing consciousness of this need.
In fact, I think that the SHACL/ShEx effort is kind of a back door to
this, and wish that validation had been step 2 of a creation +
validation suite.
kc
>> >
>> > 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>
>>
>
>
--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600
Received on Saturday, 15 September 2018 16:33:16 UTC