Extending DCAT for services #241
Conversation
…x_property_domain_range_usecase
…x_property_domain_range_usecase
…=dctype:Service. Add dcterms:conformsTo to recommended property list. Tweak cardinalities.
2. remove props whose dcat domains have been relaxed so no longer needed 3. fix dct:type value for Catalog and DataService
…ams - distracting
# Conflicts: # dcat/images/Backbone.png
…Service and associated properties
…se' into dcat-service-simon # Conflicts: # ucr/index.html
2. List classes in alphabetical order
2. Move all deprecated classes and axioms into dcat2014 graph 3. Add proposed service classes and properties into dcat.ttl
# Conflicts: # dcat/index.html
|
Shouldn't endpointLocation be endpointURL as described by @andrea-perego in #237 ? |
There was a problem hiding this comment.
Together with @pwin , I would also prefer dcat:endpointURL, as reminds dcat:accessURL and makes it explicit the it should take as object a URI/URL and not a class instance.
I would also support the inclusion of a generic "Service" class (either by re-using dctype:Service or by defining a new class dcat:Service).
Said that, I'm fine with merging this PR and address these points later - we just need to create the relevant issues.
|
dcat:endpointLocation --> dcat:endpointURL Add dct:license and dct:accessRights per GeoDCAT-AP precedent
2. shuffle Issues to best locations in document, adjust narrative in a few places 3. Add description of DiscoveryService (stub)
# Conflicts: # dcat/images/qr.png
|
@dr-shorthair said:
I have to disagree here. It would break existing implementations, and I don't think we have any use cases supporting this revision. Moreover, having them as object properties would enable cross-linking of related resources (as services and distributions). Using "URL" in the property name is consistent with similar DCAT properties ( I tend to agree that we should not allow any type of service, but I don't think we have currently a clear idea of what should be in or out. An option, already discussed, and recently suggested by @pwin in his mail, is to say that the scope is limited to online (Web?) services. On the other hand, we have the example of the Core Public Service vocabulary, which is used to describe a (not necessarily online) service delivered by a public institution, and such descriptions are meant to be available in catalogues. I cannot find a strong case to say that we cannot use DCAT for describing these catalogues. |
Note I also moved all the classes and properties that were already marked 'deprecated' in DCAT-2014 into the RDF document dcat2014.ttl, where we are gathering all the axioms removed in the DCAT-rev process. That allows the dcat.ttl document to reflect the current state without any noise (most of the deprecated classes were related to services ...). They can be reinstated later if necessary. I'm concerned that merging becomes difficult if we have too many branches open. This one covers what is likely to be the main refactor that we will make in this DCAT revision. It introduces the class |
Fix dcat:Service --> dcat:DataService Add dcat:keyword subpropertyof dct:subject (though as this was a bug in DCAT 2014 RDF, and not a revision, maybe it should be dropped entirely)
# Conflicts: # dcat/index.html # dcat/rdf/dcat.ttl
|
Just spent another hour resolving conflicts through the various branches and merges. |
This PR implements the model shown in https://github.com/w3c/dxwg/blob/dcat-service-simon/dcat/UML/DCAT-summary.png as agreed in meeting of DCAT sub-group meeting 2018-05-25
https://www.w3.org/2018/05/24-dxwgdcat-minutes.html#ResolutionSummary
4 classes are added:
ResourceDataServiceDistributionServiceDiscoveryService6 properties are added:
catalogserviceaccessService(discussion at dcat:accessURL - check constraints #124)servesDatasetendpointLocation(discussion at Example of catalogued service #237)endpointDescription(discussion at Example of catalogued service #237)This extension to DCAT is intended to satisfy requirement #56 and the matters discussed in #172 #180 #181, as illustrated in #237
The text labels and definitions might need some tweaking as discussed, and also the global (domain/range) and local (Restriction) constraints.
The intention of this pull request is to get the backbone into the RDF representation and into the draft recommendation document, so that we can refer to it while discussing other issues, and to allow us to refine other aspects in context in due course.