qjhart
commented
5 years ago After review from our Special Collection and metadata specialists, the general consensus is that a small schema.org record would be a desirable addition to the records. At least enough information to discover the orignal source of the information. That would include schema: identifier(s), license, creator, material, name, publisher and datePublished. Probably not include any descriptive fields like :about.
Two other questions have been brought up. First, is the question of the identifier. Is ucd.ttl a good name? 1) Is (ucd.) a good prefix, is there a best practice for that? and 2) the key ~.ttl~ is really more about the format and not the item. Maybe instead, we should use something like ucd.linked_data?
Now, in terms of overthinking it, since this isn't just text, and there are multiple potential formats for linked data, do we standardize on one; something human readable like ttl, or something more machine friendly like json-ld. And if we didn't specifiy, and allowed multiple versions, where to we specify format? This has been solved with data urls, but adds a level of obfuscation to the identifier,
@prefix : <http://schema.org/>.
<> rdf:type :CreativeWork ;
:creator "Sherry Wine & Spirits Co.,Inc.";
:material "paper";
:publisher "Sherry Wine & Spirits Co.,Inc.";
:name "Annual Money Saving Sale 1957";
:identifier "ark:/87287/d75k5d", "Roy Brady Collection; D202, Box 5, Folder 10";
:license <http://rightsstatements.org/vocab/InC-NC/1.0/> ;
:datePublished "1957" .Becomes this data.url
data.url:data:text/turtle;base64,QHByZWZpeCA6IDxodHRwOi8vc2NoZW1hLm9yZy8+LiAKPD4gIHJkZjp0eXBlICA6Q3JlYXRpdmVX
b3JrIDsgCjpjcmVhdG9yICJTaGVycnkgV2luZSAmIFNwaXJpdHMgQ28uLEluYy4iOyAKOm1hdGVy
aWFsICJwYXBlciI7IAo6cHVibGlzaGVyICJTaGVycnkgV2luZSAmIFNwaXJpdHMgQ28uLEluYy4i
OyAKOm5hbWUgIkFubnVhbCBNb25leSBTYXZpbmcgU2FsZSAxOTU3IjsgCjppZGVudGlmaWVyICJh
cms6Lzg3Mjg3L2Q3NWs1ZCIsICJSb3kgQnJhZHkgQ29sbGVjdGlvbjsgRDIwMiwgQm94IDUsIEZv
bGRlciAxMCI7IAo6bGljZW5zZSA8aHR0cDovL3JpZ2h0c3N0YXRlbWVudHMub3JnL3ZvY2FiL0lu
Qy1OQy8xLjAvPiA7IAo6ZGF0ZVB1Ymxpc2hlZCAgICAiMTk1NyIgLgo=
Currently, we don't really have too much of a standard for metadata creation when we mint an ARK. To date, the basic plan is that we 1) Add the minimum erc.who,what,when to the ark 2) Add a resolution service to the ARK to point to the DAMs entry.
For example, if we look at this example from the Sherry Lehmann files, we see that we've added, from ark:/87287/d75k5d
The problem is that it seems like a pretty paltry way for us to know what that identifier is for. Now, you will see that we also give a target back to the DAMS:
So currently, there is a way to see more of the information there, but I wonder if we want a more standard method of connecting this back additional metdata. For example, If you look at the Linked Data you will see we have the identifier:
schema:identifier "Roy Brady Collection; D202, Box 5, Folder 10". So,we could include that in our ark as well. There are a few methods for that. We could create our own metadata field for that.This would be carried along with the ARK, but you wouldn't see it in the UI from the browser.
Or we could use a different metadata scheme for our ARKs. They are explained in detail in the API. It's not clear to me that one is better than the other.
Schema.org
Alternatively, we could include even more schema.org metadata in the ARK. In this case, we could maintain our original metadata, and
erc.for consistency, and then use a viable subset of our complete metadata, enough to properly identify the issue.I can see three methods for this: 1) Add a schema. profile 2) embed a schema.org text record into one field, or 3) embed a data:url into a single field. Each have their own advantages and disadvantages, that we'll discuss below: In every example below, we are looking to markup the item with the following
If you have jena tools you can validate the above like:
turtle --base=foo: --syntax=turtle --output=turtle <<<$recordMetadata profile ark:/99999/fk4698d060
One idea might be to replicate a subset of schema.org. For example, predicates for identification of an item. You could presumably format these, by using the anvl key as the predicate, and the anvl value as the object. You could choose a format to differentiate between links and text, as well as a fomat to differentiate multiple values for a single key. Below is an example of this where we've used the
text/turtleformat to specify text/link and multiples.This is how we'd create records like this (using our ezid script)
This works okay, the major problems is that the format of the values within these is complicated and different then the other items eg. the
erc.entries. You've now created a set of fields in the record that need to be formatted differently, and it's hard to decide when to do that.How this could be rendered on the ezid site, is complicated by those same issues.
Embedded Schema.org ark:/99999/fk4p85hx94
This example is more closely aligns with one method of DOI identification, where the
datacite:identifier holds an complete XML record. For our case, we'd use a format liketext/turtleto format the record. For example we could store a more complete record in a singleschema.orgfield.Here's a more complete example of minting a new record, with our ezid tool.
This has the disadvantage of not being able to query on a particular field of the schema.org, but we have limited the formatting issue to a single field. If we didn't compel all users to use a standard format, we'd still have UI issues in general.
Embedded schema.org metadata as a data.url ark:/99999/fk4cv5rt32
A final potential idea to elimate the formating qustion is to provide a single anvl key, but instead, use a data.url as the value. This would allow for multiple forms of data for the
schema.orgkey. In this case, you create a data url from your tutle file, and add that as the value.This now is completely opaque to users, but it does have the advantage of providing the best out of box UI experience, since following that url would resolve to a properly formated file