Add non-required, multi-value 'inscription' field

[catlu]

One larger text box (similar to 'description' field) for filling out inscription text, and another single-line text field for inscription location.

Two OWL implementations of the CIDOC CRM vocabulary for predicate to choose from: crm:E34_Inscription OR ecrm:E34_Inscription

[hackartisan]

this is specified as a nested attribute with two properties.

@catlu can you paste links to the two predicates you've identified?

[catlu]

@hackmastera here they are: http://www.cidoc-crm.org/cidoc-crm/E34_Inscription http://erlangen-crm.org/current/E34_Inscription

[catlu]

Namespace versions: http://erlangen-crm.org/current-version This is the documentation that also gives URIs: http://erlangen-crm.org/docs/ecrm/150218/index.html. I'm unclear why the links all generate downloads though...

[hackartisan]

note we found the predicate here https://github.com/ruby-rdf/rdf-vocab/blob/28e77af943525af6e6ead5bb5fcaa326c94165e7/lib/rdf/vocab/crm.rb#L210

[catlu]

For inscription location, let's use http://www.cidoc-crm.org/cidoc-crm/E46_Section_Definition.

[hackartisan]

That looks good. For the other it can be as simple as "text" I think. It would also be nice to find an RDF type for the inscription class I will need to create. Can the inscription predicate be used for that?

Edit: by "text" i mean a predicate therefor :)

[catlu]

Okay, so recap: http://www.cidoc-crm.org/cidoc-crm/E34_Inscription http://www.cidoc-crm.org/cidoc-crm/P3_has_note and... http://bibframe.org/vocab/materialPart

[hackartisan]

This is great. We just need a predicate to use pointing from the file object to the inscription object. something like has_inscription.

[hackartisan]

oops closed the wrong issue!

[catlu]

Should the range be literal for that predicate?

[hackartisan]

@catlu no, good catch. It should be http://www.cidoc-crm.org/cidoc-crm/E34_Inscription or something broader (e.g. any superclass of E34_Inscription, on up the chain to rdfs:Class)

[catlu]

@hackmastera how about http://www.cidoc-crm.org/cidoc-crm/E37_Mark?

[hackartisan]

@catlu yep, a predicate that uses E37_Mark as its range would work!

[catlu]

Looks like http://www.cidoc-crm.org/cidoc-crm/P148_has_component is our best bet.

[hackartisan]

That works. We can also define a has_inscription if you prefer.

[catlu]

No preference with this one! I think our use of CRM will be limited enough that we won't be needing it for something else at this point.

[hackartisan]

We've decided to go ahead and use the proposed VRA ontology: VRA.hasInscription VRA.Inscription VRA.position VRA.text

[hackartisan]

@catlu what do you want this to look like when displayed on the show page?

[hackartisan]

Description box is really big -- 14 rows. Admin notes is 4, for comparison. How large do you think 'text' box needs to be?

[catlu]

@hackmastera I think 4 should be good? Since it's expandable/scrollable anyway.

[catlu]

We decided on 2 for now.

[hackartisan]

Okay this is basically done, and the implementation uses the hash / fragment URI technique which I think is great for this type of use case.

Unfortunately there's a fedora bug which gives it a downside I wasn't previously aware of -- you can delete the triple linking to the hash uri but you can't delete the node itself in fedora.

I'd be inclined to disregard this except that it isn't clear that the fedora committers see this as a bug. Which means it may or may not be something they want to fix. Here's the ticket: https://jira.duraspace.org/browse/FCREPO-1764

[hackartisan]

Refactor to use association (full, independent URI) instead of property (hash URI)