Re: ISSUE-23: A specific proposal

On Mon, Apr 27, 2015 at 11:15 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

>
>
> On 4/28/15 12:13 AM, Dimitris Kontokostas wrote:
>
>
>
> On Fri, Apr 24, 2015 at 1:18 AM, Holger Knublauch <holger@topquadrant.com>
> wrote:
>
>> In an attempt to make the discussion about ISSUE-23 [1] a bit more
>> specific, I would like to suggest the following design. I have experimented
>> with this design for a while and it appears to work nicely - both from an
>> implementation perspective and user experience. My current draft [2] uses
>> this design in its examples.
>>
>> In this proposal, the base class is sh:Shape, which carries the system
>> properties to define constraints, i.e. sh:constraint, sh:property and
>> sh:inverseProperty. sh:Shape can be instantiated and used by itself. To
>> instruct a SHACL engine, the property sh:nodeShape is used to link a
>> resource with its sh:Shape(s) that it is supposed to have. This design
>> pattern is especially suitable for people who want to avoid any conflicts
>> between existing RDFS data models and constraint checking.
>>
>> In the context of SHACL, rdfs:Class is declared as a rdfs:subClassOf
>> sh:Shape, which means that any class can play the role of a Shape, and a
>> Class can have constraints attached to it. Furthermore the rdf:type
>> property is used by the SHACL engine to link instances with their class
>> shapes, in the same way that sh:nodeShape is used. As a consequence, we
>> have a natural implementation of specialization - rdfs:subClassOf is used
>> to express sub-shape relationships.
>
>
>  If we use rdfs:subClassOf to express sub-shape relationships how can we
> distinguish between class shapes and ShEx shapes?
>
>
> I assume you mean stand-alone shapes (instances of sh:Shape) when you
> refer to ShEx shapes? You can use rdfs:subClassOf in any case. rdfs:Class
> is in this design a subclass of sh:Shape, so you could either use
> rdfs:Class instead of sh:Shape (when you want to make them sub-shapes), or
> simply use rdfs:subClassOf between Shapes (in which case an RDFS inference
> engine would infer the rdf:type. Given all trade-offs, I don't see a much
> better viable alternative to this design. What concerns do you have
> specifically? Could you give an example?
>

Assuming the shapes reside along with the data graph (which is a possible
scenario) and rdfs inference is applied on the graph, then the ShEx /
stand-alone shape will become an rdfs:Class.
In this case, a shape engine will mistaken the stand-alone shape to a
class-shape right?
Or am I missing a detail from your proposal?


>
>
> Holger
>
>
>
>
>> This design pattern is especially suitable for people who want to
>> naturally build upon the data models that already exist, and existing
>> rdf:type triples.
>>
>> I believe this design produces a very attractive user-facing syntax (no
>> bloating extra triples) while maintaining a very good level of flexibility
>> and backwards compatibility. Existing RDFS/OWL ontologies and their
>> instances can be incrementally enhanced with SHACL constraints.
>>
>> I would welcome specific, practice-oriented criticism of this design.
>>
>> Thanks,
>> Holger
>>
>> [1] http://www.w3.org/2014/data-shapes/track/issues/23
>> [2] http://w3c.github.io/data-shapes/shacl/
>>
>>
>>
>
>
>  --
>   Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia
> Association
> Projects: http://dbpedia.org, http://http://aligned-project.eu
> Homepage:http://aksw.org/DimitrisKontokostas
>  Research Group: http://aksw.org
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: http://aksw.org