Re: Bob is not a shape [Was: Re: Shapes are Classes, even if you don't use rdf:type]

<A clinic wouldn't say that every :Patient (or :Female) must
> 
> have an emergency contact, but they would say it for anyone scheduled
> for surgery.>

I assume you would propose to create a SurgeryPatient shape for this example, but you can just as well create SurgeryPatient class. In either case you need to tell the system to apply the constraint, that is somehow to associate the data about a patient scheduled for surgery with the object that carries constraints - be it using a type triple or anything else.

Yet another option is to associate the constraint directly with the class Patient by saying that if a surgery date exists, then an emergency contact must exist. For this example, it may be the most natural way to go.

<It appears to me that in all but the most trivial cases, separating
> 
> the shapes is simpler, cleaner, and more intuitive.>

I am quite certain that a typical software developer or a data modeler will not understand the difference because such difference doesn't not exist in any other paradigm they have worked with.

 I am concerned it will again put this standard in the category of "weird Semantic Web" staff that is hard to use because it comes from a viewpoint and makes assumptions that are completely unfamiliar to people in the mainstream.

Irene

Sent from my iPhone

> On Jan 26, 2015, at 8:57 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> * Jerven Tjalling Bolleman <jerven.bolleman@isb-sib.ch> [2015-01-26 13:58+0100]
>> Hi Eric,
>> 
>>> On 26/01/15 13:11, Eric Prud'hommeaux wrote:
>>> * Jerven Tjalling Bolleman <jerven.bolleman@isb-sib.ch> [2015-01-26 11:38+0100]
>>>> Hi Eric,
>> Brutal Snip
>>> I think we're actually arguing for the same solution, just factored
>>> slightly differently. You propose:
>>> 
>>>  foaf:Person
>>>    rdfs:subClassOf foaf:Agent ;
>>>    ldom:property [
>>>      ## something magic here to indicate applicability of constraint ##
>>>      ldom:recordConstraintFor <MayoContactDatase> ;
>>> 
>>>      ldom:predicate foaf:givenName ;
>>>      ldom:valueType xsd:string ;
>>>      ldom:minCount 1
>>>    ].
>>> 
>>> I propose:
>>> 
>>>  mayoHR:ContactShape
>>>    ldom:property [
>>>      ldom:predicate foaf:givenName ;
>>>      ldom:valueType xsd:string ;
>>>      ldom:minCount 1
>>>    ].
>>> 
>>>  ## something magic here to indicate applicability of shape ##
>>>  <MayoContactDatase> ldom:recordStructure mayoHR:ContactShape .
>> Shapes with the something magic is ok. But if the something magic is
>> required for shapes then the first version is as good. Because then
>> 
>> File/endpoint/service 1
>> 
>> foaf:Person rdfs:subClassOf foaf:Agent .
>> 
>> File/endpoint/service 2
>> 
>> foaf:Person ldom:property :personMustHaveAGivenNameInMyContactApp .
>> :personMustHaveAGivenNameInMyContactApp
>>    ldom:recordConstraintFor <MyContactApp> ;
>>    ldom:predicate foaf:givenName ;
>>        ldom:valueType xsd:string ;
>>        ldom:minCount 1 .
>> 
>> Is practically equivalent. This becomes more apparent when we want
>> to use shapes to document what data one can expect e.g. with
>> ldom:minCount 0. (Although I would like a ldom:requiredProperty and
>> a ldom:expectedProperty)
>> 
>> Basically I feel that the shape resource is not needed, and as its
>> not needed to meet the requirements, it should be dropped because
>> its one less thing to worry about. i.e. as simple as possible.
> 
> True, that works if the data has discriminating type arcs in the data.
> If it doesn't then it's hard to say where we hang those constraints.
> We can do the TBC trick of hanging them on rdf:Resource, but that's
> convoluted and difficult to justify to users.
> 
> By "discriminating type arc", I mean one that uniquely identifies that
> usage. For instance, clinical data may have type arcs like :Female and
> :Patient, while the constraints come from being an entry in a surgical
> roster. A clinic wouldn't say that every :Patient (or :Female) must
> have an emergency contact, but they would say it for anyone scheduled
> for surgery.
> 
> 
> Additionally, gathering constraints in a shape make it a lot easier to
> reuse shapes. Compare two ldp:Containers pointing to the same shape
> vs. one which copies all of the constraints from the other, changing
> only the value of the ldom:recordConstraintFor property.
> 
> 
>> Of course I might not see a requirement where a Shape indirection is
>> absolutely required, in which case I would like to see such an
>> requirement so we can think about it. I think Shapes where
>> introduced to avoid the need for "something magic" but as they need
>> them anyway their reason for existing has IMHO disappeared.
> 
> It appears to me that in all but the most trivial cases, separating
> the shapes is simpler, cleaner, and more intuitive.
> 
> 
>> Regards,
>> Jerven
>> 
>> PS.
>> I won't reply to list until Friday at the earliest.
>> But I will read all replies at that time and further the discussion
>> if needed.
> 
> I regret that I ran over the end of your availability window; we were
> making lots of progress.
> 
> 
>> -- 
>> -------------------------------------------------------------------
>> Jerven Bolleman                        Jerven.Bolleman@isb-sib.ch
>> SIB Swiss Institute of Bioinformatics  Tel: +41 (0)22 379 58 85
>> CMU, rue Michel Servet 1               Fax: +41 (0)22 379 58 58
>> 1211 Geneve 4,
>> Switzerland     www.isb-sib.ch - www.uniprot.org
>> Follow us at https://twitter.com/#!/uniprot
>> -------------------------------------------------------------------
> 
> -- 
> -ericP
> 
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
> 
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
>