- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Thu, 6 Feb 2014 18:53:01 +0000
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org
> OK, now I think I got what you mean. The thing is that the range of > "required" is xsd:boolean. Ah yes, I meant "domain". >> Another way round would be: >> is there any meaningful superclass shared by SupportedProperty and >> IriTemplateMapping? (So for "domain" this makes more sense.) > I don't think we need to introduce one just for the sake of it. Probably not, no. We end up with a really generic property without domain, but maybe that's not a problem. Humanity probably needs a generic vocabulary for RFC2119 :-) >> Yes and no. in the first you have the confusion that a >> SupportedProperty is not a Property; >> the hydra:SupportedProperty is the blank node; the hydra:property is >> foaf:name. > > There have been discussions (mainly with Sam) to relax this restriction so > that you can also directly point to a property instead of going through the > indirection of SupportedProperty. Mmm, the "also" bothers me there. Because then, the range of hydra:supportedProperty would be the union of rdf:Property and hydra:SupportedProperty… and hydra:SupportedProperty would still not be property nor rdf:Property. Either have the indirection or don't… but not both. > … and at the same time you would introduce hydra:optionalParameter? or not. Just hydra:parameter and hydra:required true/false. > I'm still not convinced of this terminology. "Class" and "parameter" do not > really match IMO. Fair enough. But a SupportedProperty that's not a property doesn't seem optimal either. Alternatives needed? Ruben
Received on Thursday, 6 February 2014 18:53:35 UTC