Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Domain-specific properties #112

Open
tombaker opened this issue Oct 10, 2022 · 4 comments
Open

Domain-specific properties #112

tombaker opened this issue Oct 10, 2022 · 4 comments

Comments

@tombaker
Copy link
Collaborator

Between 2001 and 2005, some domain-specific properties were added to DCMI Metadata Terms - always, in my recollection, to fill a gap in an application profile under development by a DCMI working group. These are (by profile):

In those years, the Usage Board discussed the idea of flagging these properties with the status of "domain-specific". In the end, I think we decided against doing this in part because there were so few properties, in part because we did not intend to create many more properties of such specificity, and in part because we did have a principled way to distinguish generic properties from "domain-specific" properties.

As we are now facing the possibility of approving more-specific properties in support of the Scholarly Resources Application Profile, we could revisit the idea of giving such properties a status (eg, "domain-specific"). This would give us a basis for separating the documentation of domain-specific properties from the documentation of generic properties.

@kcoyle
Copy link
Collaborator

kcoyle commented Oct 10, 2022

This varies somewhat from the diagram I did in #110 but is in the same spirit. Note that @stuartasutton replied there that "audience" had been expanded beyond the educational usage. Note also that schema.org has a handful of audience types that can be used and that have a fair amount of detail.

That said, I'm not sure about marking them as domain specific, but a diagram like the one I did that documents the domains may be sufficient. I haven't worked the classes into the diagram but have begun thinking about that.

@tombaker
Copy link
Collaborator Author

@kcoyle I like the proposal and have commented in its own issue - see #110 (comment).

@tombaker
Copy link
Collaborator Author

@kcoyle Naming the domain(s) does indeed seem to be better than just "domain-specific", which begs the question: "specific" to which domain?

@HughP
Copy link

HughP commented Oct 12, 2022

@tombaker with regard to dcterms items accrualMethod, accrualPeriodicity, accrualPolicy, is there a reason that the associated vocabularies with these terms from the collection application profile were not included? was adding dcmitype vocabulary seen as regrettable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants