Re: [dxwg] Collate existing practice in use of dct:conformsTo with DCAT (#1225)

Good to see this being looked at..  its a significant practical issue.  

I have sympathy for the view that given the adopted charter DXWG scope is limited to DCAT, not resolving data exchange interoperability architecture concerns, (in spite of the name :-) ).  There are multiple separate architectural concerns here IMHO:
1) the domain of dct:conformsTo and how to make statements about the service and data itself, rather than the DCAT object
2) how to distinguish service behaviour (API) from data access (e.g. login requirements) from data payload etc
3) how to handle fine-grained semantics regarding conformance (as expressed by profile hierarchies - or even harder canonical and comprehensive descriptions of things) 
4) Canonical identifiers for interoperability domains - what is an interoperable range for dct:conformsTo

the URI with or without / (or #) comes down to a wider issue around namespaces vs identifiers.  This needs some serious thought across communities that use identifiers to locate resources - I am thinking owl:imports and  JSON-LN context here especially.  I dont think DXWG can resolve this.

I think @andrea-perego is probably on the right track which is that for DCAT there is an assumption that an "interoperability domain" will need to adopt a register.  I suspect each domain may also need to adopt a canonical mechanism for identifying equivalence and subsumption (conforming profiles). The question is whether we want to define an interoperability domain for DCAT and declare all this, or explicitly state that DCAT profiles SHOULD define these aspects.  

Leaving it open for DCAT users to define their own mechanisms in an ad-hoc way pretty much guarantees lack of interoperability as @jakubklimek  points out.   



-- 
GitHub Notification of comment by rob-metalinkage
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1225#issuecomment-720165900 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 1 November 2020 23:04:52 UTC