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

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

Received on Monday, 26 January 2015 13:57:14 UTC