Hi everyone,
For tomorrow's discussion, here's an update of the sketch I've posted last month, explaining how a generic notion of application profile can be 'instantiated' in different technology stacks (especially, the Semantic Web stack and the 'basic' XML one)
Unfortunately I don't have time to explain more by email today. It will be during the call!
Best,
Antoine
On 03/03/16 00:51, Antoine Isaac wrote:
> Hi Karen,
>
> I guess both groups deserve better than my pencil drawing, so I've made a more decent diagram!
> 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.
>
> 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.
>
> For the second I'm not so sure we should consider it right now, as I expect the meaning of the original shapes will be harder to discuss.
>
> Cheers,
>
> Antoine
>
> 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/
>>>
>>
