[Application-profiles-ig] Musings from the YAMA project

Wed Jul 31 18:46:12 BST 2019

Nishad,谢谢!这是非常有趣和obviously very important for our work. It would be great if you could provide us with some examples based on your work. There is a heading in the Wiki for your project already but it has very little content.[1] If you cannot add them to the github wiki, let us know and we'll get them loaded there. The more ideas we have the better our work will be. I totally agree about reusability and have been thinking about the best way to make entities and statements reusable while still providing some structure for those who desire help in that area. I'll try to post something coherent in the next day or so. IDs for elements of the profile obviously are essential to that. Also, I'm wondering about trade-offs between flexibility and consistency. It sounds like your project has found a balance there that we could learn from. I'm not leaning toward any particular serialization. It is my assumption that it should be possible to express a profile in any number of serializations. While some serializations may seem to be overly-structured (e.g. XML) and others under-structured (e.g. RDF), my experience is that developers wish to work with their current set of tools. I'd like to see examples in as many serializations as we can develop, especially as a way to understand what the impact is of re-serializing our concepts. We may well discover disadvantages that would cause us to rule out some serializations from our list. kc [1]https://github.com/dcmi/dcap/wiki/Related-Projects#yamaOn 7/30/19 11:38 PM, Nishad TR wrote: >Hi Karen and all,>>Thank you for the simple vocabulary and the basic example schema.>>My experience is limited to comment on something as skilled as>vocabulary and schema formation. However, I would like to share some>random thoughts, inspirations, and lessons from our YAMA project [10].>>YAMA is an authoring format rather than an expression of application>profile itself. Matching 'DCAT-reloaded' with YAMA is more like a>'cathedral and the bazaar' comparison, so it may not be of great use.>>From the zilch knowledge, it was difficult to form the idea of a>preprocessing format. So the concepts were indirectly inspired by>Amartya Sen's thoughts from 'Development as Freedom' [1]. If we treat>the ecosystem and the community around a (computer) language or format>similar to a socio-economic system, with its transactions and>development, Sen makes perfect sense by demanding freedom for its users>as a key for the development.>>That level of freedom should be there from the use-cases to parsing and>emitting the format. Using YAML and a flexible structure built on top of>DC-DSP是一个有意的选择。在雨天,the user has the>ultimate freedom to pull out a decent YAML parser off the shelf and walk>away with their structured data.>>Reusability is a key, as we don't need to reinvent the wheel so often.>Reusability is not just about the syntax, but concepts as well. I don't>know how well I'm expressing this, but the idea is to reuse concepts>within the syntactical specification. For example, 'ID' is a concept, be>it in 'descriptions' or 'statements,' that concept doesn't change, so as>the syntax. Thus 'ID' makes more sense than 'SomethingID' as a reusable>concept. Reusing the syntax elements also reduces typos, and makes the>creation of graphical editing tools as well as validation easy. CSS is>an excellent practical example of this approach. Another such example of>a reusable concept is 'min' and 'max.' For increasing the verbosity,>optional aliases (min_cardinality is an alias of min, etc.) and optional>compounding such as cardinality=(min, max) is another neat attempt.>>Instead of strict and exclusive declaration, 'duck typing' is elegant>[5], as a 'property' is different from a 'statement' but with a lot of>common concepts and parameters, also it is declared within the virtual>(section in a single document) or real (separate files) containers.>>The syntax of YAMA is flavored with Python, PEP20 in general for the>philosophy [2]. The solid idea is simple as an authoring format, like>code, it is 'read much more often than it is written.' Snake casing and>all other Python nuances were blindly brought in to make it readable. As>a personal choice, the view of camels walking through the sand dunes is>splendid, but when that happens in my text editor, it makes me dizzy.>>Then about the constraints, I'm working on something tentatively named>as ShExY, like ShExJ or ShExC, expressing ShEx in YAML. Constraints are>much more meaningful if they are actionable. Instead of bringing up a>brand new way to express a constraint, reusing a solid idea like ShEx>makes more sense and saves much time for the authors and implementers.>YAML 1.2 natively support anchors, aliases [3] and extends so it is>natively possible to express concepts like ShEx-Extends within YAML [5],>which is difficult in any other serialization format. Also YAML-extends>permits more object oriented design for authoring.>>JSON is capable of dealing with a lot of similar things that YAML can,>but the trade-off is enormous, and the gap is more prominent than>attempts like JSON5 [8] could patch. As formats exposed to humans, JSON>and CSV are not 'humane' for me. Other than being less readable, they>don't have native support for comments. An authoring format used in>collaborative environments should support that nifty little comments to>maintain fundamental human nature of 'attempting trial and error,'>'keeping things for some other time,' gossiping, inspiring and conspiring.>>Callable IDs are so handy for YAMA as it is simple as: 'name your>puppies early and always call them by their name.' Unique ID's were used>across YAMA structure to make any element callable, which helps to>maintain a flat structure irrespective of the complexity of the>application profile. 'Zen of Python' (PEP-20) suggests - 'flat is>better than nested' [2] - and YAMA is flat by design. Thanks to YAML's>super wings called 'anchors.'>>An extensive application profile (DCAT-AP) is expressed in the>work-in-progress specification of YAMA, shows the advantage of having a>flat structure [6]. This example uses maps and ID's, and sorry about the>verbosity as thes IDs in the example were generated for automated>testing with published DCAT-AP. It is parsable with any YAML 1.2 parser.>>The work-in-progress specification's design concpet is inspired from the>'atomic design methodology' [9]. As an authoring format, it is sensible>to bottom-up as well as helps to maintain the YAML universally parsable.>>Back to Sen's freedom and development; the possibility of an application>profile is limitless. My colleague is using the theoretical perspective>of an application profile to express cultural heritage metadata, friends>using the structural aspects of application profile to record metadata>of a collection of research data including groups of CSV files in YAML.>User freedom on imagination and creativity in use cases is what going>to develop and promote application profiles.>>There may be a lot of futuristic use-cases for application profiles;>some random thoughts are:>1) Automated and on-the-fly RDF conversion from CSV and other data formats.>2) De-facto metadata manifesto for any datasets.>3) Replace DCAT and CSVW.>4) Publish static files as streamable LOD sources. (Something more like>HLS [7] replaced the need of streaming servers, a good manifest can>stream static assets as a LOD endpoint)>>YAMA stands on the shoulders of DC-DCAT, so looking forward to seeing a>lot of super-exciting developments in coming days.>>- Nishad>>>[1]https://en.wikipedia.org/wiki/Development_as_Freedom>[2]https://www.python.org/dev/peps/pep-0020/>[3]https://yaml.org/spec/1.2/spec.html#id2765878>[4]https://blog.daemonl.com/2016/02/yaml.html>[5]https://en.wikipedia.org/wiki/Duck_typing>[6]>https://github.com/nishad/yama/blob/master/examples/application-profiles/dcat-ap/1.2.1/v03/dcat-ap_1.2.1_v03.yaml>[7]https://tools.ietf.org/html/rfc8216>[8]https://json5.org/>[9]http://atomicdesign.bradfrost.com/chapter-2/>[10]http://purl.org/yama/spec/latest-- Karen Coylekcoyle at kcoyle.nethttp://kcoyle.netskype: kcoylenet