- From: Tomasz Pluskiewicz via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jul 2019 20:18:51 +0000
- To: public-hydra-logs@w3.org
> I'd still like to downgrade the mentioned `rdfs:range` from `hydra:Class to `hydra:Resource` so either `RequestSpecification` or `MediaTypedResource` from #186 (or whatever name would it be) fits by being a `hydra:Resource` I concur. The only issue I have with just the "downgrade" is that we'd completely lose any semantics. Replacing that with `rangeIncludes` give back some of that hint fo what kinds of descriptions are expected. > We shall keep as much of the backward compatibility as possible. Yes, I definitely wish to keep `[] hydra:expects some:Class` a valid construct. > Well - those approaches also claimed to be flexible. Like I said, #187 is confusing in how it brings collections into the mix. And #186 is just a tad too narrow in scope. I opened this to offer a more open solution which can potentially include SHACL and possibly unexpected extensions. Let's find middle ground. > I meant we need to think it over carefully. There are several places that would benefit from cardinality specifications. There are also other vocabs that already provide these semantics. Maybe let's ignore multipart for now. If we can get the basic structure extensible "enough", then such an extension can be developed on the side without invading the core. > In general - it feels like 'RequestSpecification'/'supportedContentType' related part is somehow similar to terms presented in #186 and both should meet same criticism and alternate ideas, i.e. @angelo-v 's approach with more generic constraint-like specifications (experiment provided with #187). It is similar. I hoped to gather the best of both ideas. -- GitHub Notification of comment by tpluscode Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/199#issuecomment-512552384 using your GitHub account
Received on Wednesday, 17 July 2019 20:18:54 UTC