Re: [dxwg] prof:inheritedFrom needs more convincing case and/or example (#642)

Is the inheritedFrom property really necessary? What if the encoding worked like the example below. 
What is actually modeled is a specification (the intention of dct:Standard, even if the actual defintion isn't clear). It's still represented by the prof:Profile class in the example.  The distinction of 'standard' and 'profile' is apparently pretty fuzzy given all the discussion about defining profile.
By treating resourceDescriptor as a qualified association from a specification to some related resource that has one or more distributions, various problems can be solved or avoided. To address @kcoyle question 1 and 3, use hasRole property could specify the 'inheritance' relationship type (override, replace, restrict, supplement), and add a property to link the ResourceDescriptor back to what it describes/constrains.  Making the range of hasArtifact a dcat:distribution, multiple representations for the resourceDescriptor target could be addressed (@kcoyle question 2 above). 

# Standard X, has validation resource SX-RS_1, 
# described using PROF, has SHEX and SHACL representations
# of validation rules.
# Profile_Y uses the constraints resource SX-RS_1  from Standard_X
#,  add validation rules as another 'hasResource' blank node,
#  and has guidance document available as MSWord doc or pdf:

<@prefix ex1: <> .
@prefix ex2: <> .
@prefix dct: <> .
@prefix prof: <> .
@prefix role: <> .

    a prof:Profile ;  # use this type to get binding to prof properties,
        # it is a subtype of dct:Standard, brings in dct properties 
    dct:title "Standard X" ;
    prof:hasResource ex1:SX-RS_1 .  # use this because we want a qualified association   

    a prof:ResourceDescriptor ;  # use this type to assign role, and bind to distributions (via hasArtifact)
 dct:isRequiredBy ex1:Standard_X          # other relations to the described standard
      # need to be accounted for, e.g. guidance, example, visualization
      # could just use dct:subject for starters
         prof:hasRole role:fullConstraints ;      # this ResourceDescriptor is the total set of
                                             # constraints needed for validating data
                                             # against Standard X for conformance
    #there are two equivalent representations of the validation rules:
 prof:hasArtifact [
  a dcat:Distribution ;
  dct:conformsTo <> ;  # the SHEX standard
  dct:format <> ;  # the JSON-LD serialization
  dcat:accessURL <constraints.jsonld> 
  ] ;
 prof:hasArtifact [
  a dcat:Distribution ;
  dct:conformsTo <> ;  # the SHACL standard
  dct:format <> ;  # the RDF Turtle format
  dcat:accessURL <constraints.ttl> 
 ] .

# then, a profile of Standard X:  Profile Y

    a prof:Profile ;
    dct:title "Profile Y" ;
    prof:isProfileOf ex1:Standard_X ;  # this is a profile of Standard X
    prof:hasResource ex1:SX-RS_1 ;
    prof:hasResource [
        a prof:ResourceDescriptor ;  # PY-RS_3 in diagram. This is not inherited from anywhere
  dct:isRequiredBy ex2:Profile_Y ;
        dct:conformsTo <> ;
        dct:format <> ;
        # these constraints are Profile Y's on top of Standard X's
        prof:hasRole role:extensionConstraints ;  # Extension Constraints are those on top of
                                                  # another base specification's
        prof:hasArtifact [
   a dcat:Distribution ;
   dct:conformsTo <> ;  # the SHACL standard
   dct:format <> ;  # the RDF Turtle format
   dcat:accessURL <extension_constraints.ttl> 
 ] ;
 prof:hasResource [
  a prof:ResourceDescriptor ;  # PY-RS_3. This is not inherited from anywhere
  dct:subject ex2:Profile_Y ;
        prof:hasRole role:guidance ;
  prof:hasArtifact [
   a dcat:Distribution ;
   dct:format <ms-word> ;  # Microsoft word document
   dcat:accessURL <profileguidance.doc> 
   ] ;
  prof:hasArtifact [
   a dcat:Distribution ;
   dct:format <adobe pdf> ;  # adobe acrobat document
   dcat:accessURL <profileguidance.pdf> 

GitHub Notification of comment by smrgeoinfo
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 6 February 2019 18:00:10 UTC