Closed michelleif closed 3 years ago
NancyL
commented
3 years ago We would need the ability to add the label along with the URI; otherwise the rdf (at least in our current templates with the resource attribute "suppressed", the URI becomes both the URI and the label as well.
michelleif
commented
3 years ago see also #2843 which will allow a user to enter a label along with the URI
NancyL
commented
3 years ago Yup, I see that one. Just pointing out that both need to be implemented together to be viable.
NancyL
commented
3 years ago I am a bit worried this is going too far. It is generally a valid thing to enter a literal within a defined range and create a blank node. Are we getting rid of that as well? That might be much too restrictive. e.g., bf:place [ a bf:Place ; rdfs:label "Charleston Lake" ] . If no range is there to create the blank node, then yes, it should restrict...
justinlittman
commented
3 years ago Can you describe this in terms of resource templates @NancyL?
NancyL
commented
3 years ago In pcc:bf2:Monograph:Work
Using bflc:PrimaryContribution (though would also apply to other nested templates as well)
Currently, we have the resource attribute "suppressible" which allows either a lookup, with this result:
https://api.stage.sinopia.io/resource/db2b22bc-e175-4474-b792-51c44e714c96 http://sinopia.io/vocabulary/hasResourceTemplate "ld4p:RT:bf2:Monograph:Work:Un-nested"; a http://id.loc.gov/ontologies/bibframe/Work; http://id.loc.gov/ontologies/bibframe/contribution :b49; ... :b49 a http://id.loc.gov/ontologies/bflc/PrimaryContribution; http://id.loc.gov/ontologies/bibframe/agent http://id.loc.gov/authorities/names/nb2014004704; http://id.loc.gov/ontologies/bibframe/role http://id.loc.gov/vocabulary/relators/aut. http://id.loc.gov/authorities/names/nb2014004704 a http://id.loc.gov/ontologies/bibframe/Person; http://www.w3.org/2000/01/rdf-schema#label "Bauer, Nancy (Gardening instructor)@en". http://id.loc.gov/vocabulary/relators/aut http://www.w3.org/2000/01/rdf-schema#label "Author".
or a literal, with this result:
<> http://sinopia.io/vocabulary/hasResourceTemplate "pcc:bf2:Monograph:Work"; a http://id.loc.gov/ontologies/bibframe/Work, http://id.loc.gov/ontologies/bibframe/Text; http://id.loc.gov/ontologies/bibframe/contribution :b53; http://id.loc.gov/ontologies/bibframe/content http://id.loc.gov/vocabulary/contentTypes/txt. :b53 a http://id.loc.gov/ontologies/bflc/PrimaryContribution; http://id.loc.gov/ontologies/bibframe/agent :b54. :b54 a http://id.loc.gov/ontologies/bibframe/Person; http://www.w3.org/2000/01/rdf-schema#label "Lorimer, Nancy".
These are both acceptable rdf, though one is a URI and one a blank node. (Whether it is semantically correct in all cases is a different question...). But if we are getting rid of using literals entirely, why did we set this property up this way? Or am I just confusing 2 issues?
justinlittman
commented
3 years ago I think the "suppressible" attribute was added to allow using the URI (http://id.loc.gov/authorities/names/nb2014004704) as the object of http://id.loc.gov/ontologies/bibframe/agent rather than a blank node. Previously, it used a blank node regardless of whether the object was a URI or a literal.
michelleif
commented
3 years ago could not come to agreement on how to pursue, closing
background Currently, in lookup fields (that is, fields of type "uri or lookup" with one or more Authorities specified in Lookup attributes), Sinopia accepts either a URI or a literal. Although this flexibility is welcome when a user does not have an appropriate URI to enter (for example, user wants to enter a URI from an authoritative vocabulary of persons, but the person they want to specify is not yet in the authoritative vocabulary), the current approach produces inconsistent RDF (sometimes the object of a property will be a literal; sometimes the object of the same property will be a URI), which will make re-use of Sinopia data by other applications difficult.
work requested by this ticket remove from lookup fields the ability to enter a literal. 1) if user enters a literal, show message "Not a valid URI" just like we do now in "URI" fields (fields of type "URI or lookup" where no Authorities are specified):
, and
2) do not offer the current "Add new literal" option
After the above changes are made: How to handle existing resources that have a literal value saved for a lookup field?
When a resource with a literal value in a lookup field is opened, show the statement with the literal as an "unused triple".
We could also generate a report of resources with literals in lookup fields so that users have a chance to fix these, even before the change is made.
end of work requested by this ticket
Note for users How to solve the problem of not having a URI? (The problem for which the ability to enter a literal was originally implemented). Some strategies: 1) follow the procedure of the external authoritative source for requesting a new entity and URI. do the lookup and choose the URI once it is available 2) create an entity in an external system like Wikidata, and use that 3) create your own URI in Sinopia, for example, if Sinopia had a "person" template, you could create a person there and use the resulting Sinopia URI (note for #2 and #3 that it is possible to enter any URI; we do not enforce using a URI from one of the Authorities offered for the lookup field)
see also #2843 which will allow a user to enter a label along with the URI