- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 10 Mar 2014 14:27:52 -0600
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, "public-hydra@w3.org" <public-hydra@w3.org>
On Mar 10, 2014, at 2:00 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote: >>>>> _:class hydra:supportedProperty foaf:name; >>>>> hydra:propertyRestriction [ hydra:property foaf:name; >>>>> hydra:required true ]. >>> >>> That's great. I like that a lot. >>> Then the range of supportedProperty is simply rdf:Property. >> >> Would you equally like it if the first triple wouldn't be there? > > Almost; "propertyRestriction" maybe might not be the correct term then. > > But how would this continue? > Would it be > > _:class hydra:propertyRestriction > [ hydra:property foaf:name; hydra:required true ]; > [ hydra:property foaf:name; hydra:writeonly true ]. > > i.e., independent restrictions like in OWL, or > > _:class hydra:propertyRestriction > [ hydra:property foaf:name; hydra:required true, hydra:writeonly true ]. > > i.e., a property definition. > Because in the latter case, "restriction" is probably not the right name; > and then we're back at the start; because it is in fact a proxy. This is what I would expect. >> The problem is that it doesn't scale. We already have "required", >> "readonly", "writeonly" and people will likely want to extend it with >> cardinality etc. > > No no, it scales as good as "required", "readonly", "writeonly". > You'd need an equal number of properties; they would just have a different domain; > i.e., hydra:Class, not hydra:PropertyRestriction. You lost me; why wouldn't cardinality (or simply "multiplicity") not have a domain of hydra:PropertyRestriction? >> So sooner or later we will need a "proxy" anyway. In this >> case, I find it better to anticipate it from the beginning as extensions >> requiring it are very likely to happen. > > I'm still in favor of sticking a name to such a proxy; > but if we have difficulties to find a name that doesn't contain "property", > I'm afraid it will always remain tricky. Could you illustrate this? Gregg > Best, > > Ruben
Received on Monday, 10 March 2014 20:28:21 UTC