- From: Rob Atkinson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Jan 2022 22:08:00 +0000
- To: public-sdwig@w3.org
Linked Data as a new technology and architecture was always only an augmentation not a disruptor I think. SPARQL endpoints, like SQL or WFS are too hard to use and make robust, so is a flawed approach. So we are left with the same problem regardless of what transport and query platform - how do you describe your data and queries. Linked Data allows "follow your nose" exploration of data - but still needs to be an adjunct to properly described data, described in the same way across datasets, data packages, APIs, queries and follow-your-nose navigation. So we are still left with the IRI based approach as the _only_ option on the table, but not yet "good enough practice" probably. The way forward we should be focussing on IMHO is making the OGC-APIs (as the data access architecture du jour) support links to descriptions - is not yet established but the technology platform is there in JSON-LD and definitely gaining some ground in spite of poor support - i.e. there is no reusable JSON context for most component data models - e.g. dcat, GeoSPARQL, SKOS. Schema.org, FIWARE, etc publish big - probably unstable dues to scope - JSON-LD contexts - if and when this becomes an ecosystem of stable reusable modules (following typical technology-at-scale evolution) its probably "good enough" practice. So perhaps we should consider holding off "best practice" refresh until OGC APIs with JSON-LD have established usage patterns - there might not be a good enough option until then? -- GitHub Notification of comment by rob-metalinkage Please view or discuss this issue at https://github.com/w3c/sdw/issues/1328#issuecomment-1020596172 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 24 January 2022 22:08:02 UTC