- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 16 Oct 2015 13:14:20 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
On 10/16/15 12:54 PM, Dimitris Kontokostas wrote: > > > On Fri, Oct 16, 2015 at 7:58 PM, Karen Coyle <kcoyle@kcoyle.net > <mailto: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 > > > what the authors of SKOS do here is *recommend* integrity constraints in > text e.g. > S14 A resource has no more than one value of skos:prefLabel per language > tag. > > at that time SHACL did not exist and there was no formal (machine > readable) way to describe all the SKOS constraints (some are described > in OWL). > if e.g. SKOS was defined today the authors would probably want to > describe these constraints in SHACL. Actually, having chatted with them, I rather doubt it. Their goal was more openness, less control. But then SKOS was intended to be widely used in a variety of contexts, and they very carefully tried not to constrain the vocabulary. Even with the integrity constraints, they have no interest in enforcing those -- even though they are what makes the vocab coherent. When you design and publish "your" vocabulary, of course, you can define any constraints you want (and on the open web, others can ignore them). The shape would be included in the vocabulary at your namespace. I still think there is a huge difference between "default" and "recommend" -- when and where will the constraints be applied? what are the penalties, if any, for non-compliance? If this is happening on the open web and not in your closed data space, then I think it's actually a pretty complex question. Because of that, I'd prefer that the definition of this be worded such that "this is shape provided by the owner of this vocabulary" -- and like an XML schema, it might be useful for you, but you can also ignore it. You also need to think about whether you would have more than one shape -- e.g. an input shape and an output shape -- and how that would be associated with the vocabulary. (Slippery slope?) kc > > To answer both Irene's comments. > I am for instance a schema designer publishing a vocabulary. I > recommend that all instances of my vocabulary should comply with the > shapes I define and I link to them from my vocabulary. > People who use my vocabulary > - may follow the sh:????ShapesGraph link and validate their instance > data with my shapes > - they can ignore my shapes completely and use their shapes (or no > shapes at all) > - or can use my shapes along with other shapes they define > > I hope this makes the intention of this issue more clear. > > Dimitris > > > > Table 2 gives the few (6) integrity conditions. > > > kc > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600> > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Events: http://wiki.dbpedia.org/meetings/California2015 (Nov 5th) > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > http://http://aligned-project.eu <http://aligned-project.eu/> > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: http://aksw.org > -- 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 20:14:52 UTC