- From: Karol Szczepański via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 May 2019 19:41:41 +0000
- To: public-hydra-logs@w3.org
>>> Without them the client has only an option to fill the operation request with plain literals. >> Untrue - knowing a property IRI client could i.e. de-reference it hoping to receive more details on that >> property, including it's range/domain declarations. It's linked data after all >This is just plain wrong and not only on one level. I just stated that client has another option, without deliberating about feasibility. > Okay, I see your point but any kind of hard-coding introduces coupling. Generally, I don't expect an API to provide me exact description of a property from these vocabularies: schema.org, RDF, RDFS, OWL, FoaF (maybe I could find few other) - these are either so popular or enforced that I acknowledge theme as _standard_ vocabs a good client should understand. The property IRI should be enough - this is where API Documentation and general pre-processing stage should come in. We can argue about which vocabs should be treated that way, but there are exceptional vocabs that should be understood by the client and I do not acknowledge it as coupling. In case of locally minted vocabs - I agree that API should be more exact, but again - throwing a property IRI that links to the locally exposed vocab is soooo easy to implement, I'd expect client to do some smart things. > You could have a multitude of properties and types from various vocabularies used in an API It may have a performance impact, but doing it somehow smart (mentioned pre-processing stage and very beginning of the client's existence) is tempting. Remember that several vocabs are using hash URL approach for their terms - this saves a lot of additional requests. I wouldn't throw out this possibility, but I agree - the more of the description provided by the API the better. -- GitHub Notification of comment by alien-mcl Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/192#issuecomment-490623016 using your GitHub account
Received on Wednesday, 8 May 2019 19:41:42 UTC