Re: Start of profiles analysis page - 2nd reply

Profiles are not of just RDF data, in the same way DCAT distributions do
not required RDF encoding...

RDF-QB provides (out-of-the-box) the means to make those fine-grained
statements about properties identified with URIs (which is the case for
RDF) - when using it for non RDF forms you need to annotate those
properties to specify the structure - for example providing an Xpath.

We need to be very careful we do not treat a current sub-optimal state as a
hard requirement here: it may be "hard" to write RDF documents - but its
effectively impossible to read many PDF documents and determine what
constraints exist. Its also hard to compare many detailed profiles to work
out what is the same and what is different - so inheritance makes things
far far simpler to process.

On the other hand - its very easy to  create flattened views, recording
which inherited parent a constraint comes from.create a PDF document of an
inheritance tree of artefacts with resolvable URIs, and also simple to
cache these, so that in general a lot less information needs to be
downloaded every time you reference a specific profile.  So simple, stable,
machine-readable profiles with URI addressable components is the easiest
model to process.  Multiple PDF documents is the hardest - yet that's our
current state.  (so i am asking myself if the desire for avoidance of
inheritance is really an assumption that profiles are defined in
human-readable, non- processable forms?)

Rob

On Mon, 11 Dec 2017 at 00:34 Svensson, Lars <L.Svensson@dnb.de> wrote:

> On Wednesday, December 06, 2017 11:44 PM, Karen Coyle [mailto:
> 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.
>
> Is that the primary audience for reading or writing Aps?
>
> And I think we should try not only to look at application profiles for
> data encoded in RDF, but also using other technologies (e. g. XML or
> perhaps even CSV [is it possible to have a profile for statistical data
> that specifies that e. g. every row is a day in a month (encoded using ISO
> format), the first column is precipitation in mm/m2, the second is
> temperature in degrees Celcius at 06:00, the third at 12:00 etc. so that
> applications will notice when the CSV format is changed?]).
> >
> > 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>
>
>