Reference DC Singapore Framework

[nicholascar]

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

[kcoyle]

I actually don't think that the DCAP is analogous to PROF, but maybe there is a useful statement to be made as a comparison. The general consensus under DCAP is that there is a single THING that is the profile in most people's minds, and that there can be extensions, like ShEx files. Or the ShEx file can be the profile, and the documentation is periferal. But when we tried to have a discussion about multiple things being 'the profile', that didn't fly. I think that the DCMI community is going to want a more "vernacular" case that meets the immediate concept in the minds of people who are working in a simple environment. So there is A THING that is a profile, not a set of things, in DC terms. That simple view could be contrasted with the more complex view. The difficulty, then, is that both are given the name "profile". I don't know how to reconcile that.

[nicholascar]

The PROF view of a profile is very much aligned with DCAT’s view of a dataset.

In DCAT, we don't have a single THING that is the dataset, rather a catalogue entry with a landing page that the dataset URI is likely to dereference to and then any number of Distributions of that dataset either directly available from the catalogue or just linked to from it.

PROF would have here a profile description, perhaps in a catalogue, that the profile's URI dereferences to and then a number of Resource Descriptors that either the catalogue would provide or just link to.

Some conceptual linking:

DCAT	PROF	Note
Dataset	Profile	Similar role for class
Dataset landing page	Dataset landing page	Expected similar behaviour
Distribution	Resource Descriptor	Similar role for class
Dataset Catalogue	Document/Profile Catalogue	Likely similar management system

[rob-metalinkage]

I dont think we can attempt to reconcile poor object identification practices in every community (and i've worked with dozens of domains and they all have to get over this hurdle at some stage to improve interoperability of data). We can just allow them to declare behaviour of the objects they want to identify - and if they find that they are declaring things inconsistently because of the nature of what they are trying to identify then they will just need to rethink - and for example mint identifiers for specific components of what they previously thought was a homogenous thing.

[kcoyle]

@rob-metalinkage If you are side-handedly referring to Dublin Core AP concepts as "poor" practices, that is insulting language and does not meet the congeniality conduct that is required by the W3C code of conduct. Please refer to the W3C Code of Ethics and Professional Conduct. PROF would undoubtedly be further along toward completion if others were encouraged and felt welcome to interact in the project.

[kcoyle]

@nicholascar Yes, I agree that PROF does appear to be a vocabulary for a DCAT-like view of profiles. It might find better reception if being aligned with the DCAT model is made explicit in the PROF document. That would show people coming from non-DCAT environments where to look to better understand the PROF view.

I am not aware of other data environments that are analogous to the DCAT model, and I admit that I still find it to be something I have to think about to make sense of. Even in the library world where "catalog" is the bread-and-butter of library data, the relationship between catalogs and their entries does not align with DCAT's model. Positioning PROF as a vocabulary for the DCAT community and any communities that have a DCAT-like model would probably help avoid objections from reviewers who have an entirely different model in mind. (I'm thinking of some of the comments that came in after the FPWD, which I think are of this nature.)

[kcoyle]

@nicholascar, @tombaker reminds me that the Singapore Framework of DCMI refers to a number of components of the application profile. In general these are not the same as the components referred to in PROF, and some are not necessarily conceived of as actual documents but as informational background. For example, Singapore Framework includes functional requirements, and this can be seen as an element of the AP development workflow whose meaning is included in the final profile but whose actual text is not. The same is true for the domain model. Note also that the domain model may be shared by any number of profiles although the model (like DCAT in relation to PROF) informs the profile.

If you wish to include a short description of Singapore Framework and how it both aligns with and differs from PROF, Tom and I might be able to provide you with a paragraph that could work.

[rob-metalinkage]

PROF and DCAT are different - DCAT is about cataloguing and PROF is about making assertions that conformance to a profile implies conformance to more general specifications and the role of resources in describing the conformance requirements. They are complementary but not at all the same or dependent on each other:

• Profiles can be catalogued in DCAT
• DCAT environments can choose to describe data and services better with PROF (via dct:conformsTo to provide a richer description and pointers to resources)

So other than design - i.e. that PROF exists to meet a bunch of DXWG requirements not covered by DCAT - there is no formal relationship between them in practice except via validity of Profile as the range of dct:conformsTo.

[rob-metalinkage]

@kcoyle i quite explicitly stated that this is a ubiquitous challenge and part of a natural learning process. Its not helpful to assume any community is perfect and cannot learn from experience or others.

[nicholascar]

@kcoyle @tombaker if you could supply us with that short description of Singapore Framework and how it both aligns with and differs from PROF, that would be really great, thanks!

Even better would be if you could also point to a resource or two that's characterised using the framework so I can try and re-characterise that same resource using PROF. As you will recall, some time ago I created a dummy DCAP profile characterised in PROF but I've not done any real DCAP or Singapore Framework instances which are really needed to be convincing.

[kcoyle]

@nicholascar There are no "singapore framework instances" - it is a very broad conceptual model and, in a sense, every application profile is a kind of instance of it. It's not intended to be instantiated as code. Think of it more as being a diagram of the topics covered in a textbook on data modeling, but in this case it's data modeling of application profiles.

@rob-metalinkage I was responding to Nick's statement "The PROF view of a profile is very much aligned with DCAT’s view of a dataset." I'll let you and Nick discuss any differences of opinion on that matter.

[kcoyle]

@rob-metalinkage You quite clearly referred to "reconcile poor object identification practices" and there is nothing neutral about the use of "poor". It is quite derogatory, and I do not accept your attempt to gloss over it with gobbledy good about "ubiquitous challenge". If you'd said that instead of "poor practices" we wouldn't be having this discussion.

[nicholascar]

@kcoyle ok, thanks for the clarification. Happy to have those descriptive paragraphs and also anything else you think appropriate. Would you like to place those paragraphs here and have me enter them into the document or would you prefer to formulate them directly in (a branch of) the document and create a PR for them? I'm happy either way.

[kcoyle]

I'll check with Tom but it's probably easiest to put it here, plus it fits perfectly with this issue topic.

[aisaac]

Everyone isn't this better for the Profile Guidance doc rather than PROF? It seems like it's about putting everything in a consistent picture, and we agreed a while ago that this is the job of the Profile Guidance (which already cites the Singapore Framework btw). No need to impose this redundant pain on PROF, which should focus on the technical aspect imo.

[tombaker]

@aisaac I agree that this is more appropriate for Profile Guidance.

[rob-metalinkage]

todo - subgroup meeting to agree and remove label for profiles vocabulary - i have added guidance label.

[nicholascar]

Since @aisaac, @rob-metalinkage, @tombaker and I all agree that this is more appropriate for Guidance, I'm removing the vocab label.

[kcoyle]

If there is still a DCAP example using PROF it should be removed from the ProfOnt document (I don't see it there anywhere but have a memory of it ...). Thanks.

[nicholascar]

@kcoyle I think you are referring to the CSIRO Dummy Dublin Core AP which is formulated according to DCAP. The example is still relevant as it's a PROF formulation of a dummy profile for illustrative purposes showing how guidance frameworks like DCAP/Singapore and PROF can work together. I'd like to leave it in the doc please.

[kcoyle]

As it references a DCMI vocabulary that is not considered current, I feel like the question should be posed to DCMI management before it appears in a W3C document. If this waits until publication, one result could be a formal objection, which can take a while to untangle. Should I ping the appropriate persons?

[rob-metalinkage]

Is it possible to identify least one uncontroversial statement about profiles or data conformance in the DCMI canon that we can be confident is a true assertion so we can illustrate how one might then formalise it? Some URI that can be referenced via the range of dct:Standard and ideally some data that claims such a thing? If not, then perhaps its better to drop references to the DCMI world until such time they can clarify what their profiles mean in practice, and perhaps using the formalism can help them test their own intentions. There are enough other driving Use Cases, including the relationships between various DCAT profiles, OGC services, Conneg-by-AP itself, Europeana schema ecosystem. Still it would be nice to provide little example and direction to the many people who profile DC in practice.

[kcoyle]

The most heavily used profiles based on DCAP are those of BIBFRAME. Example A side-by-side compare of others is here.

[kcoyle]

I should mention that those are conceptually based on DCAP, but none use the DSP constraint language which was defined as an XML schema. The BIBFRAME and Sinopia examples each interpret the basic structure (section 2) defined there, but while there is an application profile model, based on the Dublin Core Abstract Model (which in a sense pre-dates RDF usage) there is no implementable DCAP code. This is why it may be best to leave DCAP out of the document until we complete the current project.

[rob-metalinkage]

@kcoyle thanks for more info here - I think this is a useful illustration of the need to identify things unambiguously - as there are obviously multiple specifications here at different levels of abstraction. PROF doesnt care if there is a constraint language representation or not - its about being able to make statements about how these thing relate to each other. We still dont have a statement we feel would be understood and uncontroversial about things in the DCAP that allows us to unambiguously identify both the subject and object - so we may indeed be best to leave it out. Its a bit sad as i dont see any inherent reason PROF wouldnt apply and help DCAP communities clarify how things relate - but if we can't rely on any assertions as a starting point its hard to take the next step and show how.

[kcoyle]

@rob-metalinkage There's no intention in the DCAP work to identify subject and object, if you are referring to the comparative table I mentioned. That's there to help us understand current use cases, and no one has a use case to point from one to the other in practice. So far the DCAP community has not expressed a need to encode relationships between profiles, and the product of the DCAP work will be a simple vocabulary for the creation of profiles (if we determine that is possible) that is unitary.