W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > May 2018

Re: [dxwg] Definition of "Schema" (as opposed to profile)

From: aisaac via GitHub <sysbot+gh@w3.org>
Date: Mon, 07 May 2018 20:20:14 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-387192100-1525724413-sysbot+gh@w3.org>
(disclaimer: this is as much a proposal as an attempt to ask, whether I got the discussion right, by trying to relate it to things I know)

How about trying to adapt the Linked Data content negotiation (and Http-range-14) pattern here?
I.e. there's a URI for a thing in the real world ("non-information resource"), which redirects to information resources in different formats, which are expected to be ‘descriptions’ of the original resource. The idea is that these different information resources can be consumed by different applications, and thus have different function.

Adapting to our profile context:
- non-information resource: the profile itself
- information resource 1: the profile as represented as a (set of) HTML documentation
- information resource 2: the profile as represented as a SHACL definition
- information resource 3: the profile as represented as an SML schema

I believe we could say that the IR1, 2, 3 all relate to the profile resource via the ‘prof:describes’. We could type them with a class like prof:ProfileDescription.
If we need it, we could subclass this class with prof:HumanReadableDescription (for IR1) and prof:MachineReadableDescription (for IR2 and IR3).

What I'm less sure about is whether these information resources should all be semantically equivalent in the pattern. But I think it can be acceptable that resources are not semantically equivalent, when they try to describe the profile using formalisms (XML, SHACL) that do not have the same expressiveness.

GitHub Notification of comment by aisaac
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/195#issuecomment-387192100 using your GitHub account
Received on Monday, 7 May 2018 20:20:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:03 UTC