Re: Start of profiles analysis page - 2nd reply

working back through the thread ...

a profile should have have the same level of platform agnosticism as the
specification it is profiling...but may of course be a profile designed to
support a particular implementation platform.

Profiles may have one ore more relevant resources supporting implementation
specific platformas - such as SHACL constraints.

With respect to the spreadsheets defining profiles:
 Constraints on content in a general schema tend to be non-trivial - for
example "Temperature" might have constraints, for a particular purpose, on
what measurement methdology,  the units of measurement, the number of
significant decimal places, whether measurement error is reported etc.
Whilst you can describe such complex objects it requires trickery - either
a microformat (such as UML OCL) or magic knowledge about how columns are
used in conjunction with each other to build a constraint, what multiple
worksheets mean in relationship to each other etc...

But the goos news is that if, for some types of profiles, simple tabulation
of constraints is useful, it can easily be generated automatically from a
richer more flexible canonical form, and RDF compatible with DCAT,
constrained by a OWL or SHACL model - would be the obvious choice here.

The "primary audience" for application profiles informs us on the views we
need to generate - not the best way to manage the information. ( sounds
like a use case for content negotiation by profile :-)  )

Rob



On Thu, 7 Dec 2017 at 11:44 Karen Coyle <kcoyle@kcoyle.net> wrote:

>
>
> On 12/6/17 2:28 PM, Ruben Verborgh wrote:
> >> Unfortunately, the majority case appears to be that profiles are not
> >> created by coders. A look at the current generation of profiles shows
> >> that they are Word or PDF documents, most likely written by folks who
> >> are knowledgeable of the semantics of their community's metadata but who
> >> do not themselves write code.
> >
> > They can keep on writing Word and PDF documents;
> > but we cannot expect all of them to write RDF documents.
> >
> > So they might be able to define profiles in human-readable ways,
> > but not necessarily the formal specifications to validate them.
>
> Actually,this is the advantage of CVSW - Most of them can understand and
> use spreadsheets, and from those spreadsheets the CVSW -> JSON-LD/RDF
> works. The idea is to give those folks a transitional technology, not to
> leave them in the dust. In my mind, these are the primary audience for
> application profiles.
>
> kc
>
> >
> > Best,
> >
> > Ruben
> >
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
>
>