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

Proposal to the Usage Board #64

Open
osma opened this issue Sep 24, 2024 · 7 comments
Open

Proposal to the Usage Board #64

osma opened this issue Sep 24, 2024 · 7 comments

Comments

@osma
Copy link
Collaborator

osma commented Sep 24, 2024

We need a more formal proposal to the Usage Board about what we would like from them. Something like

  • consider adding the classes and properties that we didn't find in DCTerms/BIBO to either DCTerms or BIBO
    • the list could be prioritized and indicate what's proposed for DCTerms and what's for BIBO
    • most important are those that aren't found anywhere else; 2nd is non-BIBO elements; 3rd is what's already in BIBO
  • if not everything can be added to the above, coin a SRAP namespace (but we don't like this option because it's just leftovers)
  • when done, publish SRAP documents (main document, TAP, examples) on the DCMI website

In addition to the proposal we need a presentation (slides or explanatory document) to explain SRAP briefly, for example in a meeting with the UB.

@kcoyle
Copy link
Collaborator

kcoyle commented Sep 24, 2024

Found elsewhere

bibo:eissn
bibo:isbn
bibo:isbn
bibo:issn
bibo:issue
bibo:pageEnd
bibo:pageStart
bibo:presentedAt
bibo:volume
foaf:name
schema:affiliation
schema:funder
schema:funding

Not found anywhere

srap:accessibilityStatement
srap:dateRetracted
srap:embargoDateRange
srap:project
srap:role

@osma
Copy link
Collaborator Author

osma commented Oct 4, 2024

I've contacted Niklas and Tom asking for their advice on taking this to the UB.

@osma
Copy link
Collaborator Author

osma commented Jan 14, 2025

Proposal is being written in this google doc

@kcoyle
Copy link
Collaborator

kcoyle commented Jan 15, 2025

It turns out that schema:Person and foaf:Person are quite different. foaf:Person is a subclass of foaf:Agent, so in that vocabulary all persons (and organizations) are agents. In Schema, Person is a subclass of schema:Thing, and not limited to Agent roles. schema:Person is an expected type/range on properties like "actor" and "author", but is also expected with properties like "sibling" or "parent", which are not "Agent" concepts.

In scholarly works, a Person or Organization can also be the subject of the work, not an agent involved with the creation of the work.

I've added this information to the google doc as two options for defining Person and Organization in DCterms. We might, however, want to propose only the one similar to schema.org. That wouldn't change the SRAP TAP usage.

@osma
Copy link
Collaborator Author

osma commented Jan 15, 2025

I don't think foaf:Agent is "limited to Agent roles" in the sense that it could only be used for metadata fields like creator and contributor, as you seem to imply.

FOAF loosely defines foaf:Agent as "things that do stuff" and FOAF properties that have foaf:Agent as their range include foaf:maker and foaf:member (of a foaf:Group); foaf:Person is also the range for foaf:knows. Especially foaf:member is in my mind very similar to schema:sibling and schema:parent - it doesn't imply that the person/agent is actively doing something (or has done something in the past, for example created a document); merely being a member of a group (or a sibling, or a parent) is enough of "doing something" for that entity to be considered an Agent.

Maybe this is just a lumpers vs. splitters type discussion, but in my mind, foaf:Person pretty exactly matches schema:Person (and likewise for foaf:Organization vs schema:Organization). Schema doesn't have a separate, more abstract Agent subclass though; my understanding is that Schema tries to avoid unnecessary levels of abstraction and since it uses rangeIncludes and domainIncludes, abstract superclasses (to be used for domain and range declarations) are not structurally necessary as they typically are in OWL ontologies.

@kcoyle
Copy link
Collaborator

kcoyle commented Jan 16, 2025

Would you oppose giving both options to the usage board? It seems to me that they should be made aware of these options, even though some members of the board may already know of them.

@osma
Copy link
Collaborator Author

osma commented Jan 16, 2025

I'm fine with presenting both options to the UB, though as I said above, I don't see them as essentially very different. Schema chose not to have a separate Agent class, but my interpretation is that it doesn't mean that schema:Person would be broader in scope than foaf:Person.

In practice, though, not having a subclass relationship to the existing class dcterms:Agent would be a non-starter (IMHO) because dcterms:Agent is already well established and used in rangeIncludes declarations for many properties whose documentation clearly states that persons and/or organizations are expected as values.

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

No branches or pull requests

2 participants