Re: ISSUE-23: A specific proposal

Michel,

SHACL validation is launched over a dataset that has a default graph - a 
collection of triples that have been selected by whatever mechanism. 
This includes the possibility for an application to build a (possibly 
temporary) default graph containing additional triples about a IRI not 
owned by you. So technically, this provides quite a bit of flexibility. 
I agree this practice would not necessarily translate well to a pure 
Linked Data approach where all information about a resource needs to 
reside at its URI.

On 4/27/2015 6:59, Michel Dumontier wrote:
> It's fine to make a reference to a resource, but it's not OK to make 
> assertions where the subject IRI is not owned by you. for instance, 
> using the modeling I advocate,
>
> bob's file:
> bob:Issue
>   a owl:Class .
>
> holger's file, where he modifies the meaning of bob:Issue directly:
> bob:Issue
> sh:property [
> sh:predicate ex:assignedTo ;
> rdfs:label "assigned to" ;
> rdfs:comment "The assignee of an issue must be a person." ;
> sh:maxCount 1 ;
> sh:valueType schema:Person ;
> ] .
>
> michel's file, where he creates a new shape to validate that 
> bob:Issues satisfy a particular constraint:
>
> michel:IssueShape
>   rdfs:subClassOf bob:Issue
>   sh:property [
> sh:predicate ex:assignedTo ;
> rdfs:label "assigned to" ;
> rdfs:comment "The assignee of an issue must be a person." ;
> sh:maxCount 1 ;
> sh:valueType schema:Person ;
> ] .

Both approaches look fine to me. In the second approach you would still 
need to instruct the engine that all instances of Issue need to be 
verified against your extended IssueShape. This is covered by the 
existing rdf:type triples in the upper example. How would you like to 
represent this in the second approach?

Thanks,
Holger


>
>
> m.
>
> Michel Dumontier, PhD
> Associate Professor of Medicine (Biomedical Informatics)
> Stanford University
> http://dumontierlab.com
>
> On Fri, Apr 24, 2015 at 7:07 PM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>
>
>     On 4/25/15 11:25 AM, Michel Dumontier wrote:
>>     It's not good practice to annotate somebody else's URI. Is there
>>     no other mechanism by which I declare property descriptions
>>     against a target type?
>
>     To me, one of the strenghts of having URIs is to be able to
>     address/repurpose/refine resources that others have published. I
>     don't see how to avoid a (forward or backward) reference to the
>     URI of the target type. Do you have suggestions?
>
>     Thanks,
>     Holger
>
>
>
>>
>>     m.
>>
>>     Michel Dumontier, PhD
>>     Associate Professor of Medicine (Biomedical Informatics)
>>     Stanford University
>>     http://dumontierlab.com
>>
>>     On Thu, Apr 23, 2015 at 7:40 PM, Holger Knublauch
>>     <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>>
>>         On 4/24/2015 12:18, Michel Dumontier wrote:
>>
>>             in any case, there are three fundamental issues, as I
>>             currently see it
>>             1. that the specification should indicate how a shape can
>>             be defined in terms of an existing vocabulary, rather
>>             than be intrinsic to the vocabulary definition (although
>>             I don't mind if this is shown as in Example 1)
>>
>>
>>         If (for whatever reason) you don't want to put your
>>         constraints into a vocabulary file, you could use named
>>         graph/file imports to store different shape definitions in
>>         different named graphs. That's similar to taking an OWL
>>         ontology and reusing its class definitions in another file
>>         (that owl:imports the ontology). The SHACL validation is
>>         started with a parameter, which is the named graph containing
>>         the shapes for this session. So e.g.
>>
>>         File1
>>
>>         ex:Person
>>             a rdfs:Class ;
>>             rdfs:label "Person"
>>         .
>>
>>         File 2:
>>
>>         ex:Person
>>             sh:constraint [ ... ] .
>>
>>         Then start validation with File 2 as shapes graph.
>>
>>             2. that the valueType should be an IRI for a class or a
>>             shape, and we should drop sh:shape.
>>
>>
>>         I already responded to that and disagree that we should merge
>>         them together.
>>
>>             3. that a simple SPARQL query should or should not return
>>             that data are instances of shapes regardless of the
>>             validation.
>>
>>
>>         The system designer has a choice between using sh:Shapes and
>>         Classes-as-shapes. There are all kinds of engineering
>>         solutions, including named graphs, to take complete control.
>>
>>         Holger
>>
>>
>>
>
>