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

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 Thursday, 12 November 2015 20:42:08 UTC