Re: [dxwg] Differentiating Functional & Data Profiling in Conneg (#1022)

@isaac - as evidenced by conneg, there are Use Cases that require this. Its true we didnt collect other Use Cases specifically for profiles of things like services, licencing conditions, service level agreements etc..

but its also good modelling - not to use general words to describe specific things which then means we force the world into one of three anti-patterns - confusing proliferation of similar terms with unguessable scopes, reuse of the same term with different meaning or overloading a model for a specific purpose by smuggling in microformats or voilating declared semantics.

given OGC has lots of service profiles and data profiles, and DCAT itself models DataServices, with allowed use of dct;conformsTo, the need for a general term is pretty clear - so if you think that more UC write up is needed to justify then that would the way to go.  

this is the reason PROF is separate from both DCAT and Conneg-by-ap - so we can use sensible words without being bound to over-specific cases.  Its actually a lot more work to justify a idiosyncratic scope.  The equivalent is the (now deprecated) practice of using narrow owl:domain declarations for properties, which stop them being used in places they may have exactly the same semantics except applying to a different object type that the original designer thought about.

I think our conneg-by-ap edits navigate this issue - and we can introduce a DataProfile sub-class into PROF to help align scopes without crippling the model's ability to support DCAT and other use cases.





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

Received on Monday, 12 August 2019 22:19:08 UTC