Re: ShEx DSL

On 10/9/17 4:07 PM, Gregg Kellogg wrote:
>> Gregg, thanks for taking this up and doing the work. As a non-Ruby
>> person there are a few things that weren't immediately obvious so
>> perhaps we should chat at some point. I will re-iterate what Tom says
>> about the structure of the DSP - that it documents a domain model that
>> can answer the question: what things is my metadata about? I don't know
>> if that documentation function parallels the ShEx validation needs, but
>> it's the part of the DSP that I think humans need even if code doesn't.
>> I also suspect that there are things one would document even if no
>> validation is needed (I'm trying to think of an example...). So it is
>> possible that the profile has a great degree of overlap with validation,
>> but there are also areas where they may differ. Again, I know that a use
>> case is needed to make this clear, so I'm putting on my thinking cap.
> 
> What I tried to do is simply provide another way to express an ShEx schema. Perhaps a DSP is something different, that makes use of ShEx mechanisms, along with something else. There is clearly a gap of understanding here for us to explore.
> 

Sorry, Gregg. Tom and I have been struggling with trying to define a
replacement for the DSP, so I'm afraid that conversation bled into this
one. I'll continue to try to come up with use cases, and we can see
where it makes sense to meld the DSP idea with the ShEx idea.

kc

>> As for the DSL, I would like to get even more radical and make it less
>> code-y. "Do" and "end" are minor bits of code, but I'd prefer using
>> something closer to text to enclose logical clauses -- like parens or
>> indentation.  "Do" at the end of a line isn't immediately understandable
>> if one hasn't coded. Perhaps, as we said in an earlier mail, there could
>> be a step before the DSL that is even more document-like.
> 
> So, this psuedo-code I created actually _is_ Ruby, which is why it includes things such as do/done, comas and dot syntax. This is not code which is parsed (by anything other than the Ruby parser), but is simply executed. The advantage is that is potentially more accessible than ShExC/J while expressing exactly the same semantics. This doesn’t say that there is a need for something different, which is a different language with its own grammar that can be parsed and compiled into ShEx, but that is a completely different level of effort.
> 
> Gregg
> 
>> With the shapes concept, do folks think that a shape = description set?
>> Or are they not that closely related?
>>
>> kc
>>
>> On 10/9/17 10:34 AM, Gregg Kellogg wrote:
>>>> On Oct 9, 2017, at 6:01 AM, Thomas Baker <tom@tombaker.org> wrote:
>>>>
>>>> Hi Gregg,
>>>>
>>>> Thank you for starting a discussion on this!
>>>>
>>>> The example reminds me of the pseudo-code syntax that Karen
>>>> improvised for the 2009 Guidelines for Dublin Core Application Profiles
>>>> [1], using terminology (DescriptionSet, Description, Statement
>>>> template...) from Mikael Nilsson's 2008 Description Set Profile
>>>> Constraint Language [2], e.g.:
>>>>
>>>>   DescriptionSet: MyBookCase
>>>>      Description template: Book
>>>>      minimum = 1; maximum = 1
>>>>     Statement template: title
>>>>     minimum = 1; maximum = 1
>>>>       Property: http://purl.org/dc/terms/title
>>>>       Type of Value = "literal"
>>>>     Statement template: dateCreated
>>>>     minimum = 0; maximum = 1
>>>>       Property: http://purl.org/dc/terms/created
>>>>       Type of Value = "literal"
>>>>       Syntax Encoding Scheme URI = http://purl.org/dc/terms/W3CDTF
>>>>
>>>> One advantage of the DSP is that it had the notion of a graph as a set
>>>> of Descriptions (a DescriptionSet), where each Description was a set of
>>>> statements about exactly one resource.  This idea derived from the
>>>> insight that a typical library catalog record did not just describe a
>>>> book, but included information descriptive of the author (e.g.,
>>>> "1818-1883") and publisher (e.g., "Berlin").  The DSP also had a notion
>>>> of mandatory Descriptions within a DescriptionSet (e.g., a mandatory
>>>> Book description, as in the example above, with optional descriptions of
>>>> Authors), and of the type of value (e.g., literal versus "non-literal"
>>>> URI or blank node).
>>>
>>> This all seems compatible with ShEx, and with my imagined DSL.
>>>
>>>> If I'm correctly guessing your intentions, and omitting the reference of
>>>> the graph to match, I'm wondering if one might capture some of these
>>>> ideas.  I'd also like to put in a plug for snake case, which I find
>>>> marginally more readable.  So something like:
>>>>
>>>>   ShEx:DSL do
>>>>     prefix dc:   "http://purl.org/dc/terms/"
>>>>     prefix rdf:  "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>>>
>>>>     description_set "MyBookCase" do
>>>>       description "Book" do
>>>>         expect_property "dc:title", exactly: 1.times
>>>>       end
>>>>     end, at_least: 1.times
>>>>   end
>>>
>>> Yes, names in CamelCase or snake_case are simple conventions; Ruby typically prefers snake_case. Either or both could be supported.
>>>
>>> Gregg
>>>
>>>> Tom
>>>>
>>>> [1] http://dublincore.org/documents/profile-guidelines/
>>>> [2] http://dublincore.org/documents/dc-dsp/
>>>>
>>>>> I was speaking with Tom and Karen about ways to make ShEx more approachable for non-programmers by allowing an alternative syntax to ShExC and JSON. Ruby is often used for creating Domain Specific Languages, which take advantage of Ruby syntax to make programming seem less like programming. This is done, not by writing a parser, but using Ruby Blocks and instance methods to describe behavior. Examples of popular DSLs in Ruby include ActiveRecord [1]. RDF.rb uses DSLs for writing queries [2] and ActiveTriples[3] which uses an ActiveRecord-like syntax for accessing objects in a graph.
>>>>>
>>>>> As an example of what a ShEx-like DSL might look like, I took to do a pseudo-translaction of my DOAP schema [4]:
>>>>>
>>>>>     PREFIX doap:  <http://usefulinc.com/ns/doap#>
>>>>>     PREFIX dc:    <http://purl.org/dc/terms/>
>>>>>     <TestShape> EXTRA a {
>>>>>       a doap:Project;
>>>>>       (doap:name;doap:description|dc:title;dc:description)+;
>>>>>       doap:category*;
>>>>>       doap:developer IRI;
>>>>>       doap:implements    [<http://shex.io/shex-semantics/>]
>>>>>     }
>>>>>
>>>>> Which might look something like the following:
>>>>>
>>>>>     ShEx:DSL do
>>>>>       prefix doap: "http://usefulinc.com/ns/doap#"
>>>>>       prefix dc:   "http://purl.org/dc/terms/"
>>>>>       prefix rdf:  "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>>>>
>>>>>       withGraph "etc/doap.ttl"
>>>>>       matchNode "http://rubygems.org/gems/shex", using: "TestShape"
>>>>>
>>>>>       describeShape "TestShape" do
>>>>>         allowProperty "rdf:type", atLeast: 0.times
>>>>>         expectProperty "rdf:type", toInclude: "doap:Project", exactly: 1.times
>>>>>         matchAll do
>>>>>           matchEither do
>>>>>             expectProperty "doap:name", exactly: 1.times
>>>>>             expectProperty "doap:description", exactly: 1.times
>>>>>           end
>>>>>           matchEither do
>>>>>             expectProperty "dc:title", exactly: 1.times
>>>>>             expectProperty "dc:description", exactly: 1.times
>>>>>           end
>>>>>         end
>>>>>       end, atLeast: 1.times
>>>>>       expectProperty "doap:catagory", atLeast: 0.times
>>>>>       expectProperty "doap:developer", toInclude: {node ofType: IRI}
>>>>>       expectProperty "doap:impelements", toInclude: "http://shex.io/shex-semantics/"
>>>>>     end
>>>>>
>>>>> This makes use of ruby Ruby block-syntax (do…done) to describe behavior using instance methods within different class instances. The outer-most DSL describes prefix mappings, associates a graph to match (could be provided separately), and, in this case, a single node map to “TestShape”.
>>>>>
>>>>> “TestShape” is describe as a shape with either TripleExpressions (expectProperty), or shape expressions. The outer-most is taken to be a matchAll (EachOf).
>>>>>
>>>>> I’d be interested if there is interest in such an approach. Of course, this takes advantage of Ruby syntax, and to make something interoperable might require a parsable grammar. But, at least for Ruby, this might provide some advantages over raw ShExC/J.
>>>>>
>>>>> Perhaps we can add an agenda item for Tuesday.
>>>>>
>>>>> Gregg Kellogg
>>>>> gregg@greggkellogg.net
>>>>>
>>>>> [1] http://guides.rubyonrails.org/active_record_basics.html
>>>>> [2] http://www.rubydoc.info/gems/rdf/RDF/Query
>>>>> [3] https://github.com/ActiveTriples/ActiveTriples
>>>>> [4] https://github.com/ruby-rdf/shex/blob/develop/etc/doap.shex
>>>>
>>>> -- 
>>>> Tom Baker <tom@tombaker.org>
>>>>
>>>
>>>
>>>
>>
>> -- 
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> m: 1-510-435-8234 (Signal)
>> skype: kcoylenet/+1-510-984-3600
>>
> 
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 10 October 2017 03:18:15 UTC