Re: ISSUE-23: A specific proposal

On Sun, Apr 26, 2015 at 3:47 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

>  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?
>
>
I guess this goes back to the comment i made a while ago ... with some kind
of selector it would be more obvious how to choose the triples for
validation. For instance, something like:

:IssueShape
  a sh:Shape;
  sh:selector [
     sh:property rdf:type;
     sh:valueType :Issue .
 ]

 I like this because it gives us the power to generate more complex
selectors. Otherwise, we'd might just specify to look for the
rdfs:subClassOf predicate on the shape (obviously, we'd need to type our
shape to sh:Shape here too).
  what do you think?

m.


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