W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > March 2019

Re: [dxwg] prof:inheritedFrom needs more convincing case and/or example (#642)

From: Rob Atkinson via GitHub <sysbot+gh@w3.org>
Date: Thu, 21 Mar 2019 22:04:21 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-475420630-1553205860-sysbot+gh@w3.org>
"What we need here is a conclusion, which would probably be a revised example (both in code and as a one or more use cases), and a clear definition of "inheritedFrom"." - an example has been provided and an update of the definition made. the only way to progress this is to get it out for further review. 

@smrgeoinfo - it is unnecessary to make the range of artefact a dcat:Distribution - as a ResourceDescription already plays that role as a metadata carrier - recognising that this provides the advantage that such metadata is specific  to the set of roles defined.  As in dcat it doesnt stop you making any assertions about the target of the hasArtifact (or accessURL).

And note that  @smrgeoinfo (Stpehen , not Richard?) did not at all "question the need for inheritance" in any way - this property does not define inheritance. We have use cases which explicitly define the requirements for inheritance, What this property does is allow you to find which specification in an inheritance hierarchy (defined by isProfileOf property chains) defines the role of a resource.  Its a convenience to support @agreiner requirement that there is a "flat" view of profile descriptions available.  

as such, it is not the "qualified association between specifications" - we already have that in the main part of the model - this property exists solely to allow us to flatten inheritance hierarchies into a simplified graph without losing information about which part of the inheritance graph originally referenced the resource.

(I'd be quite happy to remove this and say that the flattened profile view is an implementation choice - and people could define their own idiosyncratic metadata for this information.)

Either way - at some point reviewers need to go back and examine the competency questions and the model and decide if there is better way to meet the requirements, rather than making assumptions about the meaning based on "trigger" words in names and definitions. 

The model demonstrably meets identified requirements and no concrete proposal for a simpler but equally effective solution exists - so we need to iterate on the examples and explanations and at some point just accept the best we have collectively been able to devise. 

GitHub Notification of comment by rob-metalinkage
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/642#issuecomment-475420630 using your GitHub account
Received on Thursday, 21 March 2019 22:04:22 UTC

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