Re: RDF-QB was: Re: Start of profiles analysis page - 2nd reply

On 11 Dec 2017 09:28, "Karen Coyle" <kcoyle@kcoyle.net> wrote:



On 12/10/17 3:19 PM, Rob Atkinson wrote:
> 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.

Hi, Rob. Do you have a link to RDF-QB that you can share? I looked a bit
and didn't find anything beyond a IEEE paper (that I don't have access to).


I assumed it was an informal alias for W3C RDF Data Cube, i.e.
https://www.w3.org/TR/vocab-data-cube/

Thanks,
kc

>
> 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
> <mailto:L.Svensson@dnb.de>> wrote:
>
>     On Wednesday, December 06, 2017 11:44 PM, Karen Coyle
>     [mailto:kcoyle@kcoyle.net <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 <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