- From: tombaker via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Aug 2019 14:48:40 +0000
- To: public-dxwg-wg@w3.org
@rob-metalinkage I do not see the basis for closing this issue - the three up-votes for a proposal ten months ago in [this issue thread](https://github.com/w3c/dxwg/issues/486#issuecomment-434123157)? The discussion thread above is long and quite unreadable. To close such an important issue, there really should be a clear statement of the problem, summary of the discussion, and a proposed resolution, ideally recorded somewhere else than just in Github (or does W3C accept Github issues as statements of record?). Summaries of this sort provide an intellectual audit trail for anyone in future wanting to understand the rationale for the vocabulary's design (e.g., see the extensive links in a [paper that @aisaac and others wrote on about issues in the design of SKOS](http://www.sciencedirect.com/science/article/pii/S1570826813000176)). I take @aisaac 's point that the transitive closure pattern is "just a technical trick to make available a shortcut for a chain of profileOf statements", but SKOS involved real existing concept schemes where thousands of concepts were organized in complex and overlapping hierarchies, and being able to treat relations that were declared as non-transitive, as if they were transitive, on the basis of inferencing, made sense at such a scale. How many "profile of a profile of a profile of" situations exist between real existing profiles today? Everyone has been acknowledging that real-existing profiles today are overwhelmingly stand-alone things, starting with DCAT. Proposing a design pattern based on how people may or may not design profiles in the future feels just a bit overengineered and prematurely complexified - something which, given the typical messiness involved in anything related to metadata, actually has a fairly high potential for being misused. In the lack of well-developed guidance on profiles (the "missing Rec-track deliverable"), why not err on the side of simplicity (i.e., drop the inferencing trick) and see, over time, where implementers really want to take this? Would dropping this actually break any existing implementations? -- GitHub Notification of comment by tombaker Please view or discuss this issue at https://github.com/w3c/dxwg/issues/486#issuecomment-524344112 using your GitHub account
Received on Friday, 23 August 2019 14:48:42 UTC