[Application-profiles-ig] Please review first draft

Tue Oct 20 21:07:44 BST 2020

Hi Karen, Thank you for the answers. They really clarify the picture for me. Everything you say makes perfect sense to me. My intuitive understanding of the project has always been that it was for RDF data, but I guess it was unclear to me where the edges of scope fell, and whether there was an intention to preserve some wiggle room around the edges for folks who, say, just want to assemble a set of properties to use in a database or database-driven repository (or folks who are coming at this from that kind of technical level). If some of what you wrote could make its way into the introduction, I think that would give those people a better senes of whether they could make use of the model or not. I guess it boils down to making the commitment to RDF instance data more explicit. However, having done that, it might make it easier to talk about the ways that the model is not ShEx, a schema, graph, etc. I added a few inline responses below. Cheers, John -- *John Huck*, MLIS Metadata Librarian / University of Alberta Library / he/him/his ᐊᒥᐢᑲᐧᒋᐋᐧᐢᑲᐦᐃᑲᐣ / Amiskwaciwâskahikan / Edmonton *The University of Alberta respectfully acknowledges that we are situated on Treaty 6 territory, traditional lands of First Nations and Métis people.* On Tue, 20 Oct 2020 at 08:17, Karen Coyle <kcoyle at kcoyle.net> wrote: >Thanks, John. I think you've pointed out here something that I didn't>文档中明确。让我再试一次。我们的goal was/is to profile>a template for a profile that profiles RDF *instance* data. For that>reason the profile defines:>>properties that are URIs and are defined elsewhere in an RDF vocabulary>value node type>RDF value type (from the RDF documentation)>>One might wonder why we don't include domains and ranges, but the answer>I would give there is that they support inferencing and the profile>supports *validation*. Perhaps this is a point that needs to be made in>the introduction?>Yes, perhaps. I think that many people mistakenly believe domain and range are constraints. Someone putting a profile together might want to make sure they were using a predicate "correctly" in terms of string vs. object, but we have that covered with the node type. >>That's the start. Then you ask:>>> Some of the questions that come to mind: would RDF metadata include a>> database implementation that can generate triples? That could mean just>> about any kind of data.>>Again, perhaps this needs to be made more clearly, but the profile will>be applied to RDF instance data, regardless of its origins or other>storage format. If the data isn't RDF triples, our profile should not be>workable.>>>Do we mean RDF structure? The model does pull a>> bit in both directions, making provisions on the one hand for>> cardinality (not inherently part of RDF structure) but also node types,>> etc., on the other. Which of the two principles above should carry>> greater weight?>>对吗t, and this is a conversation that Tom and I have had often, which>is that RDF is very open, but most people need to have a closed view of>their data at some point in their workflow. And in terms of RDF>standards, there should have been a "data definition" or "record>definition" standard before the creation of the validation standards.>But instead we got open RDF then RDF validation (SHACL, ShEx) and we>still don't have a standard that allows you to define your data a>priori, only a way to validate it after it exists. This is a>philosophical discussion that I don't think we want to include in our>primer, but that could be eventually part of more of an article about>why we need profiles (and more than just our simple profile).>>But we can say that our profile is a *view* over RDF triples/graphs.>Very helpful comments, thank you! Is it enough just to redefine the scope by talking about >> RDF predicates?>>We could say that the properties are predicates, but we also include>subjects and objects. I guess the question is to what extent we want to>use the RDF terms in our document. This gets us into the "meta" area ->our profile defines constraints on RDF triples/graphs but our profile is>not itself an RDF graph - it's a CSV. I'll read back through the>document to see if it crosses that fine line at any point. But we also>should discuss whether we want to point out that: a shape is an RDF>subject node; a propertyID is a URI for an RDF predicate; the value>columns are all applied to RDF objects; etc.>>Might be worth spelling those things out, yes. I also wonder about acknowledging any intended or unintended correspondences between the use of the term "shape" in this document and SHACL/ShEx. No doubt people will wonder. >Thanks!>kc>>>>On 10/19/20 3:12 PM, John Huck wrote:>> Hello all,>>>> I am still reading through the doc and everyone's comments right now,>> but wanted to raise a question, which is this:>>>> Have we fully worked through what it means to say the following two>> things and avoid a contradiction:>>>> "...the model defines only the application profile and is silent on the>> data format of the instance data that the profile constrains">(introduction)>>>> "It [the outcome] will be designed (initially) for RDF metadata" (goal)>>>> At first I was going to suggest qualifying the goal to say something>> like "designed for properties that are RDF predicates", but then I>> wondered if this might need more discussion to clarify what we mean by>> 'RDF metadata.'>>>> Some of the questions that come to mind: would RDF metadata include a>> database implementation that can generate triples? That could mean just>> about any kind of data. Do we mean RDF structure? The model does pull a>> bit in both directions, making provisions on the one hand for>> cardinality (not inherently part of RDF structure) but also node types,>> etc., on the other. Which of the two principles above should carry>> greater weight? Is it enough just to redefine the scope by talking about>> RDF predicates?>>>> Cheers,>>>> John>> -->> *John Huck*, MLIS>> Metadata Librarian / University of Alberta Library / he/him/his>> ᐊᒥᐢᑲᐧᒋᐋᐧᐢᑲᐦᐃᑲᐣ / Amiskwaciwâskahikan / Edmonton>> /The University of Alberta respectfully acknowledges that we are>> situated on Treaty 6 territory, traditional lands of First Nations and>> Métis people./>>>>>>在星期一,2020年10月19日在十四37,Karen Coyle <kcoyle at kcoyle.net>> kcoyle at kcoyle.net>> wrote:>>>> Thanks, Phil, and also for the link. Yes, I think we mainly need a>> primer to reach our first intended audience, but I do really want us>to>> make a start on normative documentation - if only because that will>be>> the document against which we test everything else we say. That said,>> I'm not experienced at writing the really formal document (I've>always>> been fortunate enough to be in standards groups where there was>someone>> better suited to take that on) so it'll be a challenge for us, but if>> it's test-able we have a shot at getting it right.>>>> kc>>>> On 10/19/20 11:15 AM, Phil Barker wrote:>> > Structure looks great, thanks for making such a great start.>Perhaps>> > more of a primer than normative specification documentation, but I>> > suspect a primer is more useful that a more formal doc right>> now--which>> > reminded me, I saw this from Leigh Dodds on good standards>> documentation>> >>>>https://blog.ldodds.com/2020/10/14/tip-for-improving-standards-documentation/>> <>https://blog.ldodds.com/2020/10/14/tip-for-improving-standards-documentation/>>>> >>> > Sorry, I couldn't entirely resist word-smithy suggestions.>> >>> > Phil>> >>> > On 10/10/2020 17:31, Karen Coyle wrote:>> >> All,>> >>>> >> I have done a first draft of our "alpha release" document:>> >>>> >>>> >>https://hackmd.io/pTp9ub_bQbO6vxZra1w-kw?view>> <https://hackmd.io/pTp9ub_bQbO6vxZra1w-kw?view>>> >>>> >> I'd like everyone to take a quick look at the structure and>> approach>> >> before I go further. It's not ready for word-smithing so please>> >> restrain those impulses and concentrate on the overall approach>for>> >> now. We can get more into detail later. Send an email or add>> comments>> >> to the document. Please do not make changes to the document at>this>> >> point or it may create confusion.>> >>>> >> Note that Nishad has updated his diagram, which I use>> throughout, and>> >> I will work in the updates over the next few days:>> >>>> >>>>>https://n1sh-my.sharepoint.com/:b:/g/personal/nishad_thalhath_org/EXhn1CYlFphLobPcUZjRe-YB9-94j9QmykBRqRlKwaMD_g?e=8hXG7J>> <>https://n1sh-my.sharepoint.com/:b:/g/personal/nishad_thalhath_org/EXhn1CYlFphLobPcUZjRe-YB9-94j9QmykBRqRlKwaMD_g?e=8hXG7J>>>>>> >>>> >>>> >> Thanks,>> >> kc>> > -->> >>> > Phil Barker <http://people.pjjk.net/phil>> <http://people.pjjk.net/phil>>.http://people.pjjk.net/phil>> <http://people.pjjk.net/phil>>> > CETIS LLP <https://www.cetis.org.uk<https://www.cetis.org.uk>>:>> a cooperative consultancy for>> > innovation in education technology.>> > PJJK Limited <https://www.pjjk.co.uk<https://www.pjjk.co.uk>>:>> technology to enhance learning;>> > information systems for education.>> >>> > CETIS is a co-operative limited liability partnership, registered>in>> > England number OC399090>> > PJJK Limited is registered in Scotland as a private limited>company,>> > number SC569282.>> >>>>> -->> Karen Coyle>>kcoyle at kcoyle.netkcoyle at kcoyle.net>http://kcoyle.net>> <http://kcoyle.net>>> skype: kcoylenet>>>>-->Karen Coyle>kcoyle at kcoyle.nethttp://kcoyle.net>skype: kcoylenet>-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.www.voudr.com/pipermail/application-profiles-ig/attachments/20201020/9247130a/attachment-0001.htm>