Re: Start of profiles analysis page - 2nd reply

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

CSVW has mechanisms for relationships between tables. (It doesn't
directly use spreadsheets, but groups of csv files.) For the tricky
constraints we're looking at ways to embed ShEx fragments, and
presumably the same could be done with SHACL or OWL. Getting the full
definition of the constraints of a dataset into the AP with anything
other than a full ShEx or SHACL document may not be possible, and if one
of those is used then I'm not sure what the conneg result would look
like - ShEx can be expressed in more than one serialization, if I'm not
mistaken, but I believe that SHACL is more limited due to its reliance
on SPARQL. Receiving a full ShEx or SHACL file would have certain
affordances, but it would be difficult, IMO, to extract human-friendly
documentation from either one. I'll ask around if anyone has tried that.

A question I have is what the users of the conneg are expecting? Mainly
in terms of what they wish to do with the resulting file. We may be
missing some use cases.

kc
p.s. I'm not totally set on using CSVW, it just appears as an existing
way to experiment with some ideas about APs. Convenient for my purposes.

> 
> 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
> <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.
> 
>     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 Thursday, 7 December 2017 08:28:03 UTC