Re: Proposal to resolve ISSUE-86

Even in the enterprise system context, there are likely to be multiple
shape definitions for the same type of resources depending on the needs of
a particular application.

I think associating shapes with a vocabulary will be useful in many
situations and it is already covered. Associating a vocabulary with a
separate shapes graph is less so and would have to be carefully explained.

I think this is where Karenıs question on the meaning of ³recommended² or
³default² comes from.

Is this a minimum set of constraints any user of a vocabulary MUST abide
by? If so, canıt they just be put in the vocabulary graph?

Or is this something else? ³Recommended² may simply mean ³recommended by
the authors of this model, but you decide if you will use them². If so,
then is this primarily for documentation purposes so that people who use
the vocabulary are informed?

If there is a default defined, can there be another set of constraints (in
addition to this set) that is specified some other way such as a
connection between shapes and vocabulary or between data and vocabulary?
If so, does it override the default or is it in addition to the default?


Irene Polikoff







On 10/16/15, 12:58 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

>
>
>On 10/16/15 2:13 AM, Dimitris Kontokostas wrote:
>> sh:defaultShapesGraph sounds fine or maybe sh:recommendedShapesGraph. I
>> won't argue about the property name
>
>Huge difference between default and recommended, and for both I would
>ask "says who?". Essentially, I can't imagine there being only one
>shapes graph for any vocabulary that is available outside of a very
>strict enterprise system.
>
>I like the idea of shapes being discoverable in some way, but
>associating a shape with a vocabulary (rather than with instance data)
>goes against my preferred approach to vocabularies, which is to follow
>the principle of "minimum ontological commitment" in the vocab and allow
>many different uses of the vocab through application profiles.
>
>This is particularly true of SKOS, which is purposely defined in such a
>way that the vocabulary contains few restrictions. cf:
>
>Key choices in the design of Simple Knowledge Organization System (SKOS)
>Thomas Baker , Sean Bechhofer, , , Antoine Isaac,Alistair Miles , Guus
>Schreiber, , Ed Summers http://dx.doi.org/10.1016/j.websem.2013.05.001
>
>Table 2 gives the few (6) integrity conditions.
>
>kc
>
>-- 
>Karen Coyle
>kcoyle@kcoyle.net http://kcoyle.net
>m: 1-510-435-8234
>skype: kcoylenet/+1-510-984-3600
>

Received on Friday, 16 October 2015 18:48:34 UTC