Antoine, I've been thinking about this, and I find your estimation of
SHACL as a foundation standard to be interesting. I'm not sure that most
of the W3C group see it that way, although quite possibly Holger does.
Others seem to see it as a language built on RDF/RDFS (and possibly OWL,
although there has been a tendency to avoid OWL in the development of
SHACL). This could be one of the gaps in thinking between members of the
SHACL group. I'm wondering if this wouldn't be a good question to pose,
using the Singapore Framework as background. It is possible that having
clarity on that would be useful for the group.
The original Shapes work didn't seem to me to be attempting to define a
foundation standard -- it was more like an application profile. But
that's yet another interesting question.
Would you feel up to posing this to the public Shapes list? If not,
would you mind if I attempt to convey your idea?
kc
On 2/25/16 7:58 AM, Antoine Isaac wrote:
> Hi,
>
> I have the following action from our last call:
>> ACTION: Antoine to articulate how SHACL relates to DC notion of
>> application profiles - simple answer (maybe too simple to be true)
>
> Let's try to see if I can do something simple... [post-mail edit: it's
> not really simple!]
>
> I'm starting with the Singapore Framework as explained in the Guidelines
> for DC APs [1]
>
> I believe that SHACL clearly belongs to the 'foundation standards'. It
> expends on the expressiveness of RDFS and OWL, actually working with a
> slightly different semantic base. But essentially it's a concrete syntax
> to express how data should be made. And I also believe W3C conceived it
> to 'fill a gap' next to RDFS and OWL.
> (btw I believe if that diagram was to be updated, OWL would also sitting
> next to RDF/S).
>
>
> The picture gets slightly more complex for a new 'SHACL box' in the
> 'foundation standards' layer to the items that are in the Singapore
> Framework's 'domain standards' layer. SHACL constraints, depending on
> their scope (and how they're 'applied'), may indeed apply:
> 1. globally to further define classes and properties from a metadata
> vocabulary, in combination with RDFS/OWL axioms,
> 2. locally, to constrain the statements in instance datasets that are
> specific to specific contexts (applications).
>
> I'm tempted to say that case #1 is quite easy. For me SHACL here serves
> as a base to express vocabularies.
>
> Case #2 is trickier. Actually I think it reflects a shortcoming of the
> Singapore Framework about DSPs [2]
>
> (disclaimer: I have to say that I was never 100% sure of these
> constituents, so the following is rather explorative)
>
> DSPs are indeed about specifying what data is good for an application.
> Which is clear. And with this in mind, it feels natural to say that
> SHACL can be used as a language to express DSPs - or at least parts of a
> DSP.
>
> The problem is that DSP is also defined as a concrete language to
> express constraints. There is no difference between an abstract language
> and a concrete syntax, as there is a difference in OWL between an
> abstract language (formal logics, roughly) and concrete syntaxes (based
> on RDF syntaxes).
>
> To be fair, it's very much likely that the DSP language was intended as
> an abtract one. But as all the examples come in XML that's no so clear.
>
> It's also not clear because in the DC AP Singapore Framework there was
> no box in the 'foundation standards' that would support the concrete
> expressions of the constraints a DSP specifies.
>
> So now we would have such a box in the 'foundation standards': SHACL.
> And we could have a direct link ('built on') between the DSP box in the
> 'Application profile' layer to the SHACL box in the 'foundation
> standards' layer.
>
> But we could also have something in the 'domain standards' layer
> in-between.
> If we think there is a place for set of rules/constraints that are not
> strictly speaking metadata vocabularies but still could constitute an
> valuable, first-order body of knowledge.
> Especially if we consider that such sets of rules/constraints could be
> re-used or extended across different applications in a domain, or even
> across domains. The same way that vocabularies are.
>
> That box could be called 'Local Constraints' or 'Application
> Constraints' or, maybe avoiding days of heated debate, just re-use the
> word 'shape': 'Application Data Shapes'.
>
> I would like to draw all this, but I need to prepare for today's call...
>
> Antoine
>
> [1] http://dublincore.org/documents/profile-guidelines/#sect-2
> [2] http://dublincore.org/documents/dc-dsp/
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|