Re: [dxwg] Service vs endpoint (#1242)

@rob-metalinkage 

 
> 
> I think there is an inherent problem with scoping a general property like dct:conformsTo to a specific range - the identifiers of protocol APIs.
> 
> Taking on board the multiple different pieces of information identified as required for the user story (independent of the priority assumed), it would appear that the requirement is for one of :
> 
>     1. dct:conformsTo be multivalued, and the objects support a type query to work out which value relates to which aspect
> 
>     2. sub-properties of dct:conformsTo for specific aspects
> 
>     3. range of dct:conformsTo to be an qualified association object that describes different aspects
> 
>     4. range of dct:conformsTo to be a canonical model for a composite specification capable of describing all aspects
> 
>     5. do nothing and leave users none the wiser about what dct:conformsTo might actually mean
> 
>     6. continue to restrict semantics of dct:conformsTo to API identifiers and formally publish DCAT as a profile of dcterms to give this restriction and its relationship to dcterms machine readable home. (leaving users none the wiser about the other aspects)
> 
>     7. something else?
> 
> 
> This is orthogonal AFAICT from the DataService vs. Distribution matter - except that for a distribution being a HTTP downloadable link a sepcial property with these semantics is deemed necessary, but that won't scale to all possible APIs and data model combinations..

It is indeed orthogonal but related, as it is part of the key properties of a data service.
Of the options I would not prefer option 3 as it complicates the usage and domain model, and then people would reintroduce it as a simple again. About option 4 I do not grasp fully your intend. 
Option 6, if I understand correctly, is to make the definition and usage much more restricted. 

As a suggestion for 7: leave it to the profile and wait for the practice. This is what we in Flanders have done. We created subproperties of dct:conformsTo to capture specific conformity cases.  Any generic DCAT user will of-course get into a situation as described in option 1. But that is as such not a weakness. In my opinion DCAT have taken the route towards covering broad aspects of cataloguing datasets and data services, and therefore it cannot be as precise as a profile. 

Nevertheless this discussion about the expectations for dct:conformsTo is important to challenge us about the expectations. Some people really want to do machine processing on it, others want to restrict is only to "official" standards, others might connect it with local implementation agreements (e.g. following an organisation's REST API guidelines). All are fine with me, and have their place under a generic dct:conformsTo. 


  




-- 
GitHub Notification of comment by bertvannuffelen
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1242#issuecomment-878836517 using your GitHub account


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

Received on Tuesday, 13 July 2021 07:09:31 UTC