search

cul / AC-RDF-Mapping

AC RDF mapping for Hyacinth fields and their MODS serializations
0 stars 0 forks source link

Breaking down the RDF description into multiple graphs #7

Open simosacchi opened 8 years ago

simosacchi commented 8 years ago

@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:

Let me know.

simosacchi commented 8 years ago

@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

melanieWacker commented 8 years ago

@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.

simosacchi commented 8 years ago

@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...

barmintor commented 8 years ago

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.

simosacchi commented 8 years ago

@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?

melanieWacker commented 8 years ago

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

simosacchi commented 8 years ago

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?

melanieWacker commented 8 years ago

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.

melanieWacker commented 8 years ago

@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