Re: ISSUE-23: A specific proposal

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 ;
  ] .


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