W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > December 2017

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

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Mon, 11 Dec 2017 01:25:11 -0800
To: public-dxwg-wg@w3.org
Message-ID: <3e5fbd52-03c9-0170-5bfe-bc5188dae6ce@kcoyle.net>


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).

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
Received on Monday, 11 December 2017 09:25:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:56 UTC