- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 13 Nov 2015 10:53:49 -0800
- To: public-data-shapes-wg@w3.org
I can't imagine how we will work with a vocabulary that doesn't have ranges defined. For example, your argument against using "sh:mincount *" is that sh:mincount is defined as an integer. This will need to be defined for sh:minCount and perhaps it is there, but I don't see it in the version of shacl.ttl that is in github. I understand that properties like sh:predicate might be defined through their usage in the ttl file (e.g. that use of sh:predicate must meet one of the conditions in the ttl), but I'm not asking that the vocabulary state where sh:datatype can be used, just what RDF type is inferred about its value. I do see a value in viewing SHACL as a closed SHACL-defined system, but I find that to be too restrictive. I also fear that it will be brittle (easily broken) and not allow for evolution of the language. kc On 11/12/15 12:41 PM, Holger Knublauch wrote: > Ranges and domains MAY work, but may also introduce complications > because we would then need to figure out what the implications are if > someone runs SHACL with RDFS inferencing ON for the shapes graph. I'd > prefer to put range info into the comments only for now, and possibly > have an alternative OWL version. OWL is likely also better to express > local restrictions, e.g. to say that sh:datatype can be used at > sh:PropertyConstraint and sh:NodeConstraint, but not > sh:InversePropertyConstraint. owl:Restrictions used via rdfs:subClassOf > usually also don't lead to inferences. This may lead to three files > published: core vocab, SHACL, OWL. > > Holger > > > On 11/13/15 1:44 AM, Karen Coyle wrote: >> >> >> On 11/11/15 8:21 PM, Holger Knublauch wrote: >>> That sounds OK to me. I believe we should aim at a situation in which >>> these two files can be mixed/overlaid without any ill side effects. >>> Basically, the SHACL file can add triples to the URIs defined in the >>> base vocab. I believe the vocab file could simply be a list of URIs, >>> possibly with rdf:type triples, rdfs:subClassOf, rdfs:labels and >>> rdfs:comments. I don't think anything else is needed. >> >> >> At least ranges, which aid in correct use of the properties. >> >> kc >> >>> >>> I had already implemented an automatic documentation generator in our >>> previous round on this topic. >>> >>> Holger >>> >>> >>> On 11/12/15 2:04 PM, Arthur Ryman wrote: >>>> I propose the following: >>>> >>>> 1. We should publish two normative files: shacl-vocab.ttl and >>>> shacl-shacl.ttl >>>> >>>> 2. shacl-vocab.ttl should be a simple RDFS vocabulary that does not >>>> contain any shape information. It should be readable by anyone >>>> knowledgeable in RDFS, but not SHACL >>>> >>>> 3. shacl-shacl.ttl should use SHACL to define the shape of valid SHACL >>>> documents >>>> >>>> 4. both files should also be automatically transformed to HTML, e.g. >>>> as in [3]. There exists XSLT for transforming RDFS vocabularies >>>> [4].This transform could be reimplemented in Javascript and integrated >>>> with ReSpec. A similar transform could be developed for SHACL >>>> documents. >>>> >>>> 5. W3C should host these files and support Turtle/HTML content >>>> negotiation as per [1] and [2]. >>>> >>>> [1] http://www.w3.org/TR/cooluris/ >>>> [2] http://www.w3.org/TR/swbp-vocab-pub/ >>>> [3] https://jazz.net/wiki/bin/view/LinkedData/JazzProcessVocabulary >>>> [4] https://jazz.net/wiki/bin/view/LinkedData/PublishingRdfVocabularies >>>> >>>> -- Arthur >>>> >>> >>> >>> >> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Friday, 13 November 2015 18:54:21 UTC