Dear all,
I've just made a not-so-beautiful but hopefully more visual attempt at representing my proposal, in the attached file.
Best,
Antoine
On 2/25/16 4:58 PM, 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/
>
|