- From: Tomasz Pluskiewicz via GitHub <sysbot+gh@w3.org>
- Date: Sat, 10 Aug 2019 20:08:41 +0000
- To: public-hydra-logs@w3.org
Okay, so I'm revisiting this currently and trying to actually implement a form element around hydra supported operation. > Having SHOULD there may end up with crafting **custom ranges** with may be actually wrong. Actually, crafting custom ranges may be a very common thing a Hydra API would do. Consider `foaf:knows`, which has range of `foaf:Person`. This range may be too broad for the client (and server). In fact, a server may never explicitly use `foaf:Person` but insist on `foaf:knows`. It may even use different ranges for this property in different contexts (ie. multiple classes which effectively subclass `foaf:Person`, even if only implicitly). That said, I come to accept that `MAY` could be a better choice and we may want to encourage some kind of lookup from a trusted source. Why? Because I realised one additional hurdle: **object vs datatype properties**. Would you agree that it's important for the client to get precise information whether a property's expected value is a resource or a literal? That is additional information which is best looked up in the source and unlike the ranges, makes completely no sense to duplicate that information for shared vocabularies. Especially that there is more that one ways this information could be conveyed. PS Still a bit worried about the size of `schema.org` though. -- GitHub Notification of comment by tpluscode Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/192#issuecomment-520176299 using your GitHub account
Received on Saturday, 10 August 2019 20:08:43 UTC