Breaking down the RDF description into multiple graphs about ac-rdf-mapping HOT 9 OPEN

@barmintor @melanieWacker I added a folder with a breakdown of the RDf description according to info to be potentially stored in id.library / URI service:
https://github.com/cul/AC-RDF-Mapping/tree/master/RDF-breakdown

Let me know if it makes sense (comments in the files explain the rationale)

Simone

from ac-rdf-mapping.

@simosacchi @barmintor I am looking at the ne5.rdf It supports the use case for AC to break the name into given name and last name, plus the affiliation attribute. Once we create and store person information in id.library/URI service, we will need to support two different conventions of describing persons. For example, personal names coming from the MARC data or from the digital collections data would not break up the name, but only use a single string. So far, for those collections we never had a use case for breaking the name up and keeping it in one string is easier for reconciliation and follows established practice. Also, instead of the affiliation, for those collections we would want to add skos:exactMatch. Is it possible to follow two different encoding conventions in the URI service?
Example:
temp:UUID a cul:Agent
foaf:name "Frederique, Kassandra"
skos:exactMatch http://isni.org/isni/0000 000416610524 .
Angle brackets don't seem to work here.

from ac-rdf-mapping.

@melanieWacker I think that being flexible is the right way to go (and here, of course, I was only representing the requirements for AC). @barmintor are there any reason why we might not want to have different ways of modeling author names, given the semantics is explicit anyway?

We shall probably broader the conversation and consider all the options that need to feed the URI service specification...

from ac-rdf-mapping.

It depends on how much responsibility you want to be contained in the data, and how much you want to relegate to a consuming application.

from ac-rdf-mapping.

@barmintor well, I guess we can always provide a fallback to the compound representation even for those names entered in Hyacinth as broken down, such that there is a certain level of consistency without losing the broken down version. Issue might still arise on how the stings are compounded (i.e. "Last name, given" or "Given + Last" etc. ), but I guess there is a degree of inconsistency anyway if the sources of information on different project represent names differently.

@barmintor @melanieWacker what do you think?

from ac-rdf-mapping.

@simosacchi not sure I am quite understanding what you are suggesting -- could you provide an example?

from ac-rdf-mapping.

Using your data here. Imagine that in Hyacinth a cataloguer working on an AC record inputs given name and last name separately, but Hyacinth stores the value both as separate values and a concatenated string, something like:
temp:UUID a cul:Agent
foaf:name "Frederique, Kassandra"
foaf:givenName "Kassandra"
foaf:lastName "Frederique"

Of course it would not be easy to go from a compound name to separate values, but at least we would have always the compound available. @barmintor @melanieWacker How does it sound as a strategy?

from ac-rdf-mapping.

So right now as I understand it, we are pretty much using the same work form, right? So would all non-AC catalogers have to put in last name, first name separately? That would be complicated from our end, because we are also dealing with all kinds of other things that may be considered part of the name string: titles, dates, fuller forms of names, etc., etc.I realize, we are starting to conflate all kinds of aspects here: tool development, controlled vocabs, etc. but it seems to factor into the issue.

from ac-rdf-mapping.

@simosacchi @barmintor -- just wanted to point you to this discussion of the MODS RDF Hydra Group. It happened before Eric and I joined those calls, but I just read through it and it is very much related:
https://wiki.duraspace.org/display/hydra/MODS+and+RDF+Call+2015-10-05

from ac-rdf-mapping.