cul / ac-rdf-mapping Goto Github PK

@barmintor @melanieWacker following the discussion in #4 would you find useful if, instead of having one RDF document for the example (as it is now), I provide different RDF documents that would break down the RDF graphs according to where we would possibly store the information?

I am imagining:

• Work level RDF document
• Author info RDF document
• RIOXX info RDF document
• Journal (or other serial) info RDF document
• others?

Let me know.

@simosacchi the example is labeled as "Journal Article with related dataset", but when I follow the exact link it shows the dataset only. So are you also including the metadata of the journal article located here: http://academiccommons.columbia.edu/catalog/ac:177633 into your modeling?

I was just looking at the funder information using RIOXX. I am unable to find a RIOXX owl or rdfs ontology online. Am I missing something?

PCDM had a general pcdm:hasRelatedObject predicate. @barmintor is it ok to have subproperties of pcdm:hasRelatedObject to model more explicit relationship semantics --e.g. using bf:dataSource to connect a paper (a work) to a dataset (another work)

@amberbilley , please go ahead and share your work on an RDF representation of the Columbia Organizational Structure. No need to upload all the data, just examples of RDF descriptions.

We can start the discussion on how to model the data on the issue here (which predicates, URI vs local ID, etc.)

Please branch out the repo and add your work in a folder when you are ready.

This work is intended to inform how to store/share this info in URI Service / id.library.

We can track here the issue that are emerging. so @cul/ac-metadata-rdf-wg please provide feedback.

@simosacchi FYI: I noticed that this example is using the language code from ISO 639-1. In our other collections we are generally using ISO 639-2

Which predicate to use for volume and issue information? @melanieWacker

Also, in terms of modeling, I was thinking of modeling a journal entity either at the work or collection level connected to the article (another work) using bf:partOf (or something like that), so is it ok to push the issue and volume info at the article level?

I know the current example does not include thesis information, but the BIBO ontology would be useful to look at when we get there.

Just wondering if a local property for affiliation is necessary. How about https://schema.org/affiliation?

@barmintor @melanieWacker I have been using several blank nodes constructs in my example (for modeling info about authors, identifiers, etc.)

@barmintor Is this an acceptable approach to store that info in FEDORA? What about when we will have URIs for people for id.library? For indexing/presentation purposes do we need to replicate the info in the stored RDF descriptions or providing the URI is enough?