[Application-profiles-ig] URIstem test

Tue Jun 9 00:11:50 BST 2020

All, I will copy this also to the github area where we are discussing value types and values,[1] but as not everyone is receiving the notices of comments on github, I thought this might be a good time to spread the word to this list. Tom and I had an impromptu brainstorming session this morning, based on the github comment that I made where I realized that the use of URIstems was problematic for our table structure. [2] Tom responded with the thought that we might be using the value space for significantly different things. [3] (Tom, speak up if I mis-characterize your view!) Adrian also weighed in on this. [4] During our chat Tom and I fiddled around with a google spreadsheet trying out various ideas. [5] We did NOT solve the problem but at least agreed on what we thought was unresolved. Here are some things you may notice about the spreadsheet (which I based on a section of Phil's example [6]): 1. Line 6 has the URI stemhttp://viaf.orgas the "value constraint" (the column we've often called "value") 2. We have added another column for the value shape linking identifier (@author) 3. The statement in line 6 holds the property sdo:author, its cardinality, and value type and value 4. The statement in line 9 gives the information that the author shape entity must be of type bf:c_Person (I'm making this up; just assume it is a legitimate RDF class for this entity) 5. To show a use of the entity @book I added a new entity for the series in which a book may appear. 6. The table has columns for namespace and namespace prefix (both Tom and I prefer that we not mix data types within a single column) and I moved it to the bottom of the table for purely editorial reasons; I think some human readers may be better served by presenting the "meat" of the profile before this type of detail. Problems remain in this table. My main concern is that it might seem odd to profile developers to have the key information about the author (line 6) separate from the author entity information on lines 8 and 9. We tried to come up with a way to have an author entity that has all of the author information, somehow moving the value type of author entity and the constraint to the @author entity node of the table. What we came up with was an unattractive kludge. If you have ideas on how to solve this, please speak up and/or copy what is hear and make the modifications that you think will work. kc [1]https://github.com/dcmi/dcap/issues/61［2］https://github.com/dcmi/dcap/issues/61#issuecomment-640082342[3]https://github.com/dcmi/dcap/issues/61#issuecomment-640514538[4]https://github.com/dcmi/dcap/issues/61#issuecomment-640572492[5]https://docs.google.com/spreadsheets/d/1pFLYCgHBQgEDliJKUrLYESOYHZJEfV31MeNeEVNuivo/edit#gid=0[6]https://github.com/dcmi/dcap/blob/master/prototypes/bookclub/ap.csv-- Karen Coylekcoyle at kcoyle.nethttp://kcoyle.netskype: kcoylenet