Re: ISSUE-87: Shall we publish RDF files for the SHACL namespace?

On 11/14/2015 4:53, Karen Coyle wrote:
> 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. 

See

https://github.com/TopQuadrant/shacl/blob/master/src/main/resources/etc/shacl.ttl

lines 864 onwards:

sh:AbstractMinCountPropertyConstraint
     ...
     sh:argument [
         sh:predicate sh:minCount ;
         sh:datatype xsd:integer ;
         ...
     ] ;

In an OWL version this could become (also dropping the unpopular 
"Abstract"):

sh:MinCountPropertyConstraint
     ...
     rdfs:subClassOf [
         a owl:Restriction ;
         owl:onProperty sh:minCount ;
         owl:allValuesFrom xsd:integer ;
     ] ;

and then sh:PropertyConstraint "inherits" sh:minCount":

     sh:PropertyConstraint rdfs:subClassOf sh:MinCountPropertyConstraint

OWL-aware tools should be able to provide guided editing based on that 
structure. rdfs:range is another, less flexible, option. As long as we 
publish these variations in different files, people and tools can chose 
the version that they prefer.

HTH
Holger


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

Received on Friday, 13 November 2015 23:14:39 UTC