Rename Resource Descriptor class

[nicholascar]

The Resource Descriptor class' name may not convey its intention well. This name needs to be reconsidered with discussion about it here.

[agbeltran]

Discussion about this name also happening in https://github.com/w3c/dxwg/issues/404

[aisaac]

For the record, for a similar notions, other proposals (my F2F3 diagram [1] and our F2F postits [2]) have used the following words, without making a final decision:

• profile description/specification/expression
• distribution/publication

Implementation may also be an option...

[1] https://docs.google.com/drawings/d/1dHkpwKwUwMgS1RqSCTPO3uOoRiY_qNk0z5bhXJlYi4Y/ [2] currently in the first page of https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/

[smrgeoinfo]

also a related suggestion w3c/dxwg#529, copied here In the Figure 1. OWL [owl2-overview] diagram of this ontology, the ResourceDescriptor class is basically an associationClass that associates a resource with the Profile in some role with some purpose. There might be multiple representations of this resource available, and these will have different linking information (URL, Mime Type etc.). The dcat:Distribution class is defined to model exactly this; shouldn't the target of the 'artifact' predicate/role be dcat:Distribution? The model would look something like this:

[kcoyle]

I'm not convinced that the resource descriptor is necessary. If most supporting artifacts are one to one with a resource descriptor then they can be reduced to a single thing, and that thing is the supporting resource, which has a role and a physicality (MIME type). In the few cases where one provides a resource in more than one physical format (e.g. ShEx in JSON-LD and in RDF) it's not a big deal to describe it twice. Basically, this provides a level of indirection for a small number of cases that can be handled without it. (And BTW I would discourage people from keeping around the same data in multiple formats - that's a maintenance nightmare.)

I really like calling the resource a "supporting resource" and that resource would be a Thing - an artifact.

I also do not think that we should assume that profile artifacts will be described with DCAT. In fact, we haven't so far seen any proposed metadata for describing profile artifacts beyond role , dct:format, and profileOf. There's no title, no description, no license ... basically there is no metadata for the content of the artifacts themselves.

[makxdekkers]

@kcoyle In my reading, prof:Profile is on the same level as dcat:Dataset and prof:ResourceDescriptor is on the level of dcat:Distribution, with prof:hasArtifact being the equivalent of dcat:downloadURL. I see no reason that we could not add more properties to prof:ResourceDescriptor, adding things like title, description and licence to it. I do think that we need a new name for it. I would suggest something like ImplementationResource or ProfileDistribution.

[andrea-perego]

@makxdekkers said:

@kcoyle In my reading, prof:Profile is on the same level as dcat:Dataset and prof:ResourceDescriptor is on the level of dcat:Distribution, with prof:hasArtifact being the equivalent of dcat:downloadURL. I see no reason that we could not add more properties to prof:ResourceDescriptor, adding things like title, description and licence to it.

+1

I do think that we need a new name for it. I would suggest something like ImplementationResource or ProfileDistribution.

I would strongly support prof:ProfileDistribution.

[kcoyle]

@andrea-perego The problem with "implementation resource" is that not all of the resources are directly related to implementation, such as various explanatory documents for humans. You could argue that EVERYTHING aids implementation, but I think that many people will associate implementation with code. The problem with "profile distribution" is that distribution is well understood by DCAT users but the profile work here is not to be dependent on knowledge of DCAT.

I still question whether an abstract layer is needed. I know that it is common to have them in OO design but this is a vocabulary, not code. As a vocabulary, it is to be at least in part human-facing. An abstract layer would need to be justified by a significant presence of one-to-many situations - that is, one resource description to many distributions. I don't think that is the case here. And as I've said above, it's generally a bad idea to have multiple versions of the same thing due to the need to keep them in sync.

Note: the one-to-many in FRBR - which some cite in relation to DCAT design - is a frequent case and thus is a viable design for library catalogs. But FRBR is not a good model for standards documents where precision and 'equivalence' matter. The "many" in FRBR can vary widely, creatively, such as translations of poetry, movies made from books, or entirely updated versions of textbooks. It's an entirely different use case. For profiles, even certain minor differences could result in a different profile, not a new distribution. If you have one profile with terms A, B, C, D and another with A, B, C, D, E you cannot use the same validation rules with both. Minor differences count.

[makxdekkers]

@kcoyle What worries me here is that you seem to question fundamental aspects of the model. If that's the case, there is no way we can publish a FPWD. As far as understand, the profile model is quite similar to the DCAT model. I don't think that is a problem. Rather, I think it is a strength. Personally, I see no problem with ProfileDistribution -- if the class is well defined, a reader that knows about DCAT would see the similarity, and a reader who doesn't know about DCAT would just read the definition and that's it. Of course there are one-to-many relationships, at least the way I understand the model. In the case of DCAT-AP, https://joinup.ec.europa.eu/release/dcat-ap/12 is the prof:Profile and each of the things linked at the bottom of that page are instances of prof:ProfileDistribution. They are actually listed under a heading "Distributions"(!) If you look at https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_fb8e6a3e2_b372e_b4be3_b8cc6_b938c7a2181ce (unfortunately not a nice URI), there you have the format and a download link (prof:hasArtifact). In my mind, your example of the two profiles X(A,B,C,D) and Y(A,B,C,D,E) are two different profiles and would be two instances of prof:Profile, with each having their own a set of ProfileDistributions, e.g. https://joinup.ec.europa.eu/release/dcat-ap/11 vs. https://joinup.ec.europa.eu/release/dcat-ap/12.

[andrea-perego]

I share @makxdekkers's point.

[kcoyle]

Again, @makxdekkers I think you are looking at this from a DCAT point of view, and what we are charged with developing is not a DCAT-dependent standard. We need to assume that many folks who use the profile guidance and terms will have no knowledge of DCAT - and mau not have the use cases that formed the DCAT model. We have removed the link to the DCAT document from the guidance document for that reason. If we want to test the one-to-many hypothesis we need examples beyond DCAT, IMO. DCAT should not be our base.

But, yes, we can publish this as a FPWD because anything can change between the FPWD and subsequent drafts. The purpose is to gather feedback. We should definitely make it a point to gather feedback from beyond the DCAT community. If people like the model as is, then that's what we'll go for. But let's look at profiles with the use cases and requirements of profiles in mind.

[makxdekkers]

@kcoyle No, I wasn't looking at this from a DCAT perspective. As I wrote, people looking at the profile ontology who had no knowledge of the DCAT approach would just look at the spec and take the definition of ProfileDistribution, and if it was described well, would just take it like that. Did you look at my example of DCAT-AP and the way that profile is described and distributed? I honestly do not see another way to publish a profile and a set of associated files like the ones published for DCAT-AP. I would love to see your counterproposal of how it could work without ProfileDistribution objects to describe the various files associated with the profile. I am not worried about the feedback we get on a FPWD -- I just think that we, as the group that proposes it, need to agree on the top-level model. If we don't, we should not go out for FPWD, is my opinion.

[kcoyle]

@makxdekkers,

I think this is really a moot discussion due to the nature of the profiles ontology. Look again at the profiles ontology and you'll see that there are NO terms describing the profile itself or the resources, other than a small number of relationships between profiles and resources. Here are the properties associated with the main classes:

Profile: hasProfile hasResource isProfileOf isTransitiveProfileOf hasToken

ResourceDescriptor: hasArtifact dct:conformsTo dct:format hasRole isInheritedFrom

Compare that to how rich the descriptions of dcat:Catalog and dcat:Dataset and dcat:Distribution are. There is nothing of that nature in the profiles ontology. The properties given in @smrgeoinfo 's diagram are not included in the ontology, and there isn't much to tell us what information would live where. It isn't even clear to me what properties one could include to describe a profile at the prof:Profile level because it's current a pretty vague concept, but I suspect a property set would be more sparse than one has in DCAT because what "makes up" the profile could vary greatly. In fact, we don't know much about what would make up a profile, if all "resources" would have the same author or institution, etc. None of this is specified in the ontology.

In any case, while @smrgeoinfo's model may appeal, it is not representative of what we are offering as a FPWD. If you do read that into the profiles ontology then you should present a proposal to the group and see what comes of it.

[makxdekkers]

@kcoyle Now I am confused. I had the impression that we were discussing the current model at https://w3c.github.io/dxwg/profilesont/, and in particular, the diagram at https://w3c.github.io/dxwg/profilesont/profilesont.svg, not @smrgeoinfo's model higher up in this thread. I reacted to your comment that you were "not convinced that the resource descriptor is necessary". Your argument, based on the properties for Profile and ResourceDescriptor in the current model, seemed to imply you wanted to change the model as it is now, associating the dct:format, prof:hasArtifact and prof:Role directly with prof:Profile and removing the prof:ResourceDescriptor from the model. If that was not your intention, then I have completely misunderstood.

[kcoyle]

Yes, I was responding to Richard's model. In @smrgeoinfo 's model, ResourceDescriptor has only Role and the meat of the description of the resource is in the distribution/artifact. I question that for the case of profiles.

The only thing else I can say is that I do not believe that there will be distributions for profiles if the definition is the same as it is in DCAT and if a profile = dataset:

Definition: | A specific representation of a dataset. A dataset might be available in several different forms, and these forms might comprise both different serializations or different schematic arrangements of the same data. Examples of distributions include a CSV file, a netCDF file, or a data-cube

There might be distributions for resources, but then resources become logically equivalent to datasets and the profile is a catalog. A profile, as I read profilesOnt, is an abstraction that is defined by one or more objects. Those objects are not for the most part in any way equivalent, so they are not distributions of the profile because they are not "the same data."

I still see profiles as not being analogous to DCAT because DCAT has a "center" in the format of a dataset, and profiles have at best a named graph that is defined by its objects. The structure might be similar, but the concepts of dataset/distribution and profile/resource are not at all the same.

[makxdekkers]

Agreed, the definition of prof:ProfileDistribution should not be the same as dcat:Distribution. It should at least be more flexible, to include the types of objects associated with DCAT-AP (listed as Distributions, i.e. PDF/DOC/ODT specs, Turte file, SHACL file, SVG/PNG/EA diagrams).

[kcoyle]

Makx, We'll just have to agree to disagree. I do not consider those files "distributions" in the DCAT sense - for the reasons I have given above - and I also don't consider them "distributions" in the natural language sense since they are parts that make up a whole, not distributions of an existing set of data. They are different objects with different data content, albeit about the same conceptual thing. Some may actually be transformations of each other (e.g. the ODT and DOCX), and I think that is a special relationship that should be noted, but others are independently created, and many have unique content. For these reasons, I see no reason to call them distributions, which might cause confusion with dcat:Distribution. They are better described, IMO, as they are in the profiles ontology as resources or objects with roles. The objects themselves might be said to have distributions, and that would cover the transformed files, like ODT/DOCX/PDF if they aren't independently created, but we need to think about that more (profilesOnt doesn't get into that kind of detail or definition). In FRBR those would be different manifestations because items must be exact copies of each other, but FaBio treats different serializations or file formats as different items, which also makes sense.

I'm going to try a different diagram style, one that is more "thing"-based than the ones we have now. I'll see if that can help clarify my thinking. It would help me to see some datasets that are defined in DCAT. I can find documents, but I'm not finding a way to look at the DCAT descriptions of catalogs and datasets and distributions. That would help me a lot, thanks.

[nicholascar]

I agree with @kcoyle that we should avoid 'distribution' in any part of this classe's name as that would give the DCAT-based impression that this class is a representation of the Profile's whole which won't be the case. We know people will use this class to link in guidance documents, validation files etc. which are only parts of the whole profile.

In Issue https://github.com/w3c/dxwg/issues/572 we are circling around 'profile object' or other, similar, terms that indicate a part of the (Profile's) whole, rather than a distribution of the profile as a whole. I like that direction better and wonder about the general use then of :Profile dct:hasPart :ThisClass .. since the decinition of dct:hasPart is "A related resource that is included either physically or logically in the described resource.", to me, this class does represent some such object, with the additional requirement we think we have to indicate a role for that part.

If this class were called ProfileObject (I'm not trilled by "object" as, like "resource" it's generic) and had the properties we currenly indicate for it (a dct:format, dct:conformsTo, prof:role) then we might have something that's simpler (using more well-known DCT terms, fewer custom terms) and yet able to do what ProfileDescritpr was designed to do.

@rob-metalinkage: would use of dct:hasPart to indicate object of this class from a Profile object be problematic? Assuming this object still then lead to the artifact itself?

[kcoyle]

Note that we could also use dct:hasFormat which, in spite of its name, means "A related resource that is substantially the same as the pre-existing described resource, but in another format." So if the same resource/object/thing is available in multiple formats (like DOCX/ODT or SVG/PNG) you can indicate that they are the same content in a different serialization/format. There are different ways to fit that into the model, I've got some diagrams in progress but don't know if we should continue this here.

[nicholascar]

@kcoyle I think it reasonable to continue this here. We haven't got a better place for this really.

I know the dct:hasFormat property and I think what you're saying is that you could have something like this:

# just testing these names, not promising anything!
:Profile_X a prof:Profile ;
  prof:hasPart 
    :ProfileObject_M , 
    :ProfileObject_N , 
    :ProfileObject_Y , 
    :ProfileObject_Z .

# a guidance doc
:ProfileObject_M a prof:ProfileObject ;
  :hasRole role:Guidance ;
  dct:format <http://w3id.org/mediatype/application/pdf> ;
  dct:hasFormat :ProfileObject_Z .  # i.e. there is another 'form' of this 'ProfileObject'

# the same thing as :ProfileObject_M excpet it's a PDF, this is a Word doc
:ProfileObject_N dct:format <http://w3id.org/mediatype/application/msword> .

# a SHACL constraints document
:ProfileObject_Y a prof:ProfileObject ;
  :hasRole role:Validation ;
  dct:format <http://w3id.org/mediatype/application/msword> ;
  dct:hasFormat :ProfileObject_Z ;
  dct:conformsTo <http://www.w3.org/ns/shacl#> .  

# all the same properties as :ProfileObject_Y except for dct:format
:ProfileObject_Z dct:format <http://w3id.org/mediatype/application/ld+json> .

Is that what you meant? I can see that this would be a quick way to represent parts of profiles that are substantially the same with just a format difference. Here I'm using my above proposed dct:hasPart to indicate these 'ProfileObjects' within the overall Profile. the hasRole is giving all of the parts meaning, so we haven't lost anything from the original ontology, but this all seems simpler and more intuitive than Descriptors, Deistributions etc.

[makxdekkers]

I agree with calling the class prof:ProfileObject. I'd rather define a special property prof:hasProfileObject because I don't think a specification or SHACL file is a 'part of' a profile in any sense of the word. Using dct:hasFormat to link a ProfileObject for a DOC file to a ProfileObject for an ODT file is OK ; it's exactly what the property is for.

[nicholascar]

If we use a custom property like prof:hasProfileObject then we loose any speedup regarding easily understanding what the prof:Profile <-> prof:ProfileObject relationship is, although it may be able to be inferred from the class naming.

I guess it depends what you think a 'profile' is. In the dummy DCAP profile I've made, https://github.com/CSIRO-enviro-informatics/csiro-epub-dcap, there is a PDF doc explaining things (Guidance) and Word form (dct:hasFormat) and constraints in RDF (not SHACL but DSP; equivalent to SHACL for this discussion's purposes). How would those all not be dct:hasPart from the main Profile object? They are all parts of it!

[kcoyle]

Here are crude versions of what I meant with dct:hasFormat. I think one of these is more or less as you coded above. I also think that the model could allow both, depending on what users need at the time.

[kcoyle]

I agree with @makxdekkers about "hasPart" - because there is no whole, really. And we can decide to shorten hasProfileObject to something like hasProfObj if we want, leaving the label as 'has profile object'. In fact, given that this is the prof vocabulary, it could be prof:hasObject which includes the necessary context.

In the end I don't care greatly what we call it, but it's not a 'part' in my mind.

[smrgeoinfo]

is prof:hasObject different from dct:relation, other than a (implicit?) domain restriction?

[kcoyle]

My answer here is pretty much same as to 'conformsTo' - it depends on how specific you want to be. Could there be related files (and dct:relation is ANY related file) that are not profile objects? Would the addition of prof:role be enough to make that clear? I also would think about how one might search in a heterogeneous graph space in order to produce a suitable use case. (p.s. prof:hasObject might well be defined as a subclass of dct:relation.)

[nicholascar]

OK, I agree that dct:hasPart can be shelved as it gives a part/whole impression that we can't guarentee to support.

@smrgeoinfo: I worry that dct:relation just doesn't tell you much and is probably too broad, as @kcoyle suggests! Karen may be right though taht duck typing anthing indicated by dct:relation with a prof:role might work, as would a prof:hasObject subPropertyOf dct:relation.

In general, I like to reuse well-known properties and then specialise their range object with duck typing (so extra properties, not subclassing) rather than creating specialised properties with subPropertyOf, since most people don't use inferencing and won't then know to relate the specialised property back to the general property. This might be more art than science though; I have no number to back up my assumption.

@rob-metalinkage: we need to hear from you here.

[smrgeoinfo]

I like the idea of having a :role on any dct:relation.

[nicholascar]

@smrgeoinfo it's the qualified relations pattern (http://patterns.dataincubator.org/book/qualified-relation.html) all over again, something I pushed hard for in the early DCAT work (now adopted in places).

[makxdekkers]

I am not sure what would be gained by declaring prof:hasProfObject a sub-property of dct:relation. In fact, it has been argued by some people at DCMI that dct:relation is the implicit super-property of any predicate -- as every predicate defines a relationship between a Subject and an Object, but that tells you basically nothing. I do not fully understand how one would assert a Role on a dct:relation. The basic pattern is

:Something dct:relation :SomethingElse

Where would the Role go?

[makxdekkers]

@kcoyle I just wanted to react to you statement above: "I do not consider those files [...] "distributions" in the natural language sense". The case is that at least one maintainer of an application profile, https://joinup.ec.europa.eu/release/dcat-ap/12, does call those associated files 'Distributions' so I am not sure that our discussion about the use of this term is relevant. As long as the definitions of classes and properties in the ontology are clear, there should not be a problem how they are called.

[nicholascar]

What about Profiling Resource?

Using "Profiling", we avoid issues to do with interpretations of Implementation, Supporting etc. as Profiling can just be defined under the umbrella of the definition and class for Profile and then this thing - the ...Resource - is just a thing that gets the profiling done and we don't have to worry about any more defining than that.

[aisaac]

@nicholascar I'm not so enthusiastic about it, honeslty. I'd prefer ProfileResource as I think "profiling" may be confusing (i.e. one could understand that the resource profiles a profile). And then we're not far from ProfileObject already suggested.

[rob-metalinkage]

After going through the nature of ResourceDescriptors in issue w3c/dxwg#769 it feels we are in a better place to reconsider this. I would say the shape of model is confirmed, but perhaps it is worth revisiting the name in order to make it easier to grasp the nature of things?

options:

1) leave it as ResourceDescriptor 2) change to ProfileResource 3) something else

i think there is no issue with making a change as we dont have an installed base (i plan implement as soon as we feel we have processed this first round of feedback and stablised namings.)

so @kcoyle should we create a new issue to have a vote (or put one at the end of this long one)

[kcoyle]

We could, but w3c/dxwg#769 pretty much negates the name "ProfileResource" since that issue points out that the graph is not about the resource but about the resource role. So until we resolve that issue we can't resolve this one.

[kcoyle]

Also, w3c/dxwg#769 is far from resolved and there is still a major question about the nature of the profile resource. (Sorry for the multiple comments - it's very early and I'm rushing to catch a train. I'll stop now until I get settled and can think things out.)

[kcoyle]

Thanks, Richard. We can set up a vote on that. I do have one question about the use of dcat:distribution: What would be the URI that is the object of :hasArtifact in that diagram? Is it the URI of the artifact itself? (That, to me, would be correct.) If it is, what is the role of dcat:accessURL in that scenario?

[smrgeoinfo]

What I was thinking is that the prof:hasArtifact/dcat:Distribution is about the specific representation (as a resource, or rdf-triple-object) of a resource describing the profile in some role (what prof:ResourceDescriptor does). The dcat:accessURL is the location where that representation can be 'GET'ed on the web. The dcat:Distribution value for the prof:hasArtifact can be a blank node (as in the example I posted); it could be assigned an identifier if that is useful. I think a possible source of confusion here is that the current approach links from a profile, which I view as a resource (FRBR work), to related resource (resourceDescription) representations (hasArtifact) directly, instead of linking the profile resource to a description resource, recognizing that both of these might have one or more representations (realized as dcat:Distributions, which are resources of a different type, that conform to some specification and have some representation format). I'm fully aware of the issue that different representations of a resource can be accessed at different distribution:accessURL, or via content negotiation. It is a profile WG issue about how to communicate the content negotiation (http accept header syntax) options in the metadata, saving clients from feeling around with HEAD requests and guessing what the response means. Using different distribution:accessURL can avoid the problem by using dct:conformsTo and dct:format for each distribution.

[kcoyle]

@smrgeoinfo The problem that I have with the DCAT distribution is that it is not properly reified - nothing in it states that the triples there are statements about the file found at the access URL. If those statements are to hold true for the access URL then the access URL should be the object of 'hasArtifact'. The other option is to explicitly reify the distribution to the file being described using "rdf:about". The third option, which I think cannot be the case, would be to require that the URI that is the object of "hasArtifact" and the subject of the thing of type "dcat:Distribution" be required to respond appropriately to content negotiation for requests for a certain file type.

I am also assuming that under this design, two files in different formats are different distributions . This was confirmed elsewhere by @makxdekkers.

[makxdekkers]

@kcoyle You make an interesting observation about the "reification" of dcat:Distribution. As far as I know, all users of DCAT take for granted that the triples are indeed about the file found at access URL even if the specification does not explicitly say so.

I do, however, agree that @smrgeoinfo's diagram at https://github.com/w3c/dxwg/issues/573#issuecomment-438688720 contains one level too many. I would think that prof:ResourceDescriptor is on the same level as dcat:Distribution -- they share a lot of properties, with prof:ResourceDescriptor just adding type and role.

[kcoyle]

@makxdekkers Thanks, Makx. I'm sure that the DCAT users are all well-versed in the DCAT format, so this doesn't throw them off. The target audience for anything related to profiles generally is much broader so we can't count on users having "inside information." For that reason, conforming to basic RDF is more important.

As to your second point, this has been discussed in w3c/dxwg#769 and in particular at this comment. dcat:Distribution is a class for a "downloadable file", if I understand correctly, and describes the nature of that file. The role defined in PROF is not the nature of the file, it is a relationship between the profile and the file (called 'artifact' in PROF). The same file can have different roles, either in the same profile or in other profiles. So the file description and the role are not one-to-one, and therefore need to be separated. Otherwise, every use of a file with a different role will require a new description, which isn't a good idea, especially when it comes to sharing.

An example of this is the library community that is developing an RDF vocabulary for cataloging, and now has software that allows anyone to create a profile from that same vocabulary based on their own needs and cataloging software. There will be thousands of profiles as libraries using this vocabulary, world-wide, create one or more profiles for their own work. This means that there will be a lot of sharing of the basic vocabulary, some sharing of profiles, and there are also common rules for input that will undoubtedly be "profiled" to fit the many application profiles. The fact that these resources will not be held neatly in silos but will be widely shared means that 1) the descriptors need stable URIs (not bnodes) and 2) the roles and descriptors need to be separate so that they can vary independently.

I really see the DCAT use case and the Profiles use case to be very different, and that is why I don't think that just adopting DCAT's Distribution is a good fit.

[nicholascar]

@kcoyle

...every use of a file with a different role will require a new description, which isn't a good idea, especially when it comes to sharing.

If you wanted to use a file already used for Profile A with Role X but now for Profile B woth Role Y then yes, you would “require a new description”. The use, and thus the association of that file to a Rrofile - the ResourceDescriptor - is different.

If you wanted to use a file for Profile A with Role X for Profile B with Role X.... ta da, that’s what isInheritedFrom is for!

If sounds like your would wish to see a register of ResourceDescritors for reuse, perhaps in a community like libraries. Not impossible at all but that, like registers of Profiles themselves need not be handled in PROF but is cataloguing of PROF resources.

[makxdekkers]

@nicholascar Can you explain "that's what isInheritedFrom is for"? Is ResourceDescriptor B inherited from Profile A, or would there just be one ResourceDescriptor that 'is inherited from' both Profile A and B?

[rob-metalinkage]

So as far as I can tell we have reconsidered the available alternatives and circled back to the existing model. Please review w3c/dxwg#842 to see if that helps any - i think its perhaps an improvement that is closer to familiar words for concept.

we could also consider an entailment rule (can this be done as a owl:propertyChain?)

CONSTRUCT { ?pr dct:format ?f . } WHERE {
?pr prof:hasArtifact ?a ?a dct:format ?f
}

[rob-metalinkage]

@kcoyle - missed your last comment as i was replying - I do accept your logic about a more general case, so we need to be explicit that the case you put forward is supported. I dont want to throw out the DCAT compatibility however, as we have at least one motivating Use Case to answer for. Hopefully the suggestion above allows us to have our cake an eat it too. Your argument does convince me we dont want to normatively align with DCAT - it can remain as an optional alignment.

[rob-metalinkage]

So - to get back to the issue - is there a concrete proposal for an alternative name we could vote on? (i am not averse to making the name more role-centric BTW) If not, i suggest we leave it open ion the next PWD and close if we get no better suggestions after comment cycle,

[nicholascar]

I've previously mentioned Profile Distribution as an informal alignment with DCAT and I like the idea of using Profile... as that prevents any other words needing definition like Resource etc.

I probably now prefer Profile Part as that's even clearer - the thing is part of a Profile and we could consider using dct:hasPart to indicate it, rather than prof:hasResource which seems to do the same thing and reduces the number of new properties.

[makxdekkers]

Sounds good to me. Just a minor point would be that it should not be excluded that the Profile Part could contain all constraints the Profile defines.

[nicholascar]

@rob-metalinkage what do you make of the concrete proposal to rename the class to ProfilePart with the requirement from @makxdekkers that it be defined to not exclude containing all that the Profile defines?

[nicholascar]

The proposal in w3c/dxwg#1061 is to rename ResourceDescriptor to ProfileDistribution to better conceptually align with the DCAT model (Profile/ProfileDistribution aligns with Dataset/Distribution and this also follows the ADMS precedent which uses Asset/AssetDistribution).

Since continuing discussion is occurring in w3c/dxwg#1061, I'm marking this issue due-for-closing in favour of discussion there.

[aisaac]

This is the place where the discussion on naming should happen. So I'm pasting the elements of w3c/dxwg#1061 that are relevant here:

From @rob-metalinkage : My preference has always been for a change to a better name for ResourceDescriptor, and I never much liked hasResource anyway. ProfileObject is really really awful however - every thing in a vocabulary could be called ProfileObject and no interpretation is possible. Given that the prime reason the ResourceDescriptor exists is as a qualified role association a name closer to that might be better. all the other things we want to add to it (as per DCAT distribution), format, conformsTo etc are all clues about its role too that are easier to machine-read than descriptive text ). Could people live with ResourceRole and hasResourceRole ?

From: @nicholascar we already have a ResourceRole class (it was formerly Role but we changes it at 2PWD). How about ProfileDistribution, a la DCAT?

From: @rob-metalinkage : agreed - ResourceRole is already better for the Role descriptor itself so agree best to rename ResourceDescriptor as making it more obvious this akin to DCAT distribution pattern will help, particularly as we have decided not to make profiles dependent on DCAT. We have an informal consensus that the ResourceDescriptor placeholder needs changing.