Antoine,

On Thursday, March 03, 2016 12:51 AM, DCMI Architecture Forum wrote:

> I guess both groups deserve better than my pencil drawing, so I've made a
> more decent diagram!

Looks impressive...

> I have made an additional distinction between shapes that would be at the
> level of the application (application-specific shapes) and optional, more
> general domain-standard shapes. I'm contemplating there might be shapes
> at different levels of genericity. More specifically, a DSP would include some
> (application-specific) shapes, and other more general shapes may not sit in
> any DSP.

I'm not quite sure I understand what would be the difference between an application-specific shape and a domain shape. Could you give an example?

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

> About your question: I think it's worth asking the Shapes group your first
> questions - on SHACL as a foundation standard and its relation to RDFS/OWL.
> Feel free to pass my material to the Shapes group, as I won't have time to
> work on this in the coming days.

FWIW I agree that SHACL (or whatever will eventually be the preferred shape language) is a foundation standard, just as we probably would have had XML Schema as a foundation standard, had DCAP been based on XML and not on RDF. But it might be that I interpret SHACL as something it isn't...

Best,

Lars

> On 3/2/16 6:00 PM, Karen Coyle wrote:
> > 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/
> >>
> >