Re: Organizing the requirements

Hi Eric,

some feedback:

The feature to categorize the requirements into groups (or shall we call 
them "profiles") makes a lot of sense. The one currently called "small" 
is indeed a lowest common denominator that we should hopefully be able 
to agree on. I assume that different stakeholders can create their own 
profile to highlight which features are most important to them, because 
there is no single field "priority" that everyone would be able to agree on.

Where I am struggling is the categorization of "expressivity" and the 
associated language snippets. This is IMHO sometimes comparing apples 
with oranges. For example, many items called "SPIN" are really just 
general SPARQL expressions, and they look rather ugly and not how SPIN 
users would write them. In particular, each example could either be 
represented as a plain spin:constraint using SPARQL or with a 
higher-level SPIN template. And once you use SPIN templates you 
basically get the same syntax as Resource Shapes. Furthermore, the SPIN 
examples will always be the most verbose because they are fully 
executable while the algorithms to interpret the ShEx, Resource Shapes 
and OWL must be "hard-coded" into the respective engines. So basically 
if we want to call these items "SPIN" then we should split this into two 
formats: SPIN (with SPARQL constraints) and SPIN (with templates). For 
the time being I believe the current "SPIN" items should just be called 
"SPARQL". I can fill in the two SPIN variations separately (if I find 
the time, sigh).

Finally, we should make sure this doesn't look like an "either-or" 
bake-off of different technologies while in reality most of this is 
complementary (Shapes are the high-level vocabulary, SPARQL provides the 
formal semantics, SPIN is a meta-vocabulary for Shapes and ShExC may 
serve as an alternative compact syntax).

I also think we should stop calling this "Dublin Core" requirements - DC 
is just one group among many others that will have input.

Thanks,
Holger


On 10/21/2014 8:34, Eric Prud'hommeaux wrote:
> * Holger Knublauch <holger@topquadrant.com> [2014-10-16 11:18+1000]
>> On 10/14/2014 9:20, Eric Prud'hommeaux wrote:
>>> I propose that folks review the Dublin Core Application Profiles
>>> requirements to get some shared terminology. I've done my best to
>>> create a hierarchical version faithful to their database. I hope
>>> this is a bit easier to review
>>> <http://www.w3.org/2014/10/rdfvalreqs/>. The js I used to make
>>> expandable lists disables clicking on links so you have to e.g.
>>> shift click in order to open in a new tab (sorry!).
> [SPARQL expressivity discussion elided.]
>
> Per Holgers point below, I've moved the requirements into a JSON file
> (not JSON-LD yet) <http://www.w3.org/2014/10/rdfvalreqs/reqs.json>.
> There's a (crappy) group selector and only ~25 reqs in the "small"
> group. Go to <http://www.w3.org/2014/10/rdfvalreqs/>, click "small"
> to turn it on, "DB" to turn it off and "Expand All" to see the whole
> list at once.
>
> The groups are:
>    DB: everthing in the DB (except 205, 206, 207 which are new).
>    workshop: what came up during the 2013 workshop.
>    small: a group that I hope we can agree on and buid upon.
>    DCAP: stuff in the DB that came from the Dublinc Core group.
>    ericP: most of small plus stuff I think worth adding.
>
> If anyone else wants a vanity group, just send me the list of reqs
> like: [R25, R183, Rπ].
>
>
>> I second the view expressed by others yesterday that we should try
>> to associate the requirements with corresponding SPARQL queries (and
>> OWL equivalents if possible) and hope that we can later reuse those
>> formal representations for the actual implementation of the standard
>> Shapes. Of course, if a pattern already has an equivalent in OSLC
>> Resource Shapes or ShEx or OWL Closed World then this should be an
>> annotation to the pattern too.
>>
>> To make this more specific: would it make sense to move from
>> "expressivity" items to "shapes" or "patterns" and collect those in
>> a semi-formal format? Other specs have this button that allows you
>> to see a snippet in Turtle, RDF/XML, JSON-LD etc, and we could do
>> something similar. Each such Shape candidate would have a
>>
>> - name (including what could become the local name of a URI for the pattern)
>> - arguments (e.g. cardinality shape has min/max and a property as arguments)
>> - description
>> - generality/reuse/importance level (could later lead to "profiles")
>> - example(s) in prose and RDF instances
>> - SPARQL implementation of the constraint check
>> - OWL-Closed-World implementation
>> - ShExC implementation
>> - Pointers to ShEx, Resource Shapes etc. equivalents
>>
>> Such a model may also better address Peter's request for measurable
>> and comparable evaluation criteria. And the requirements work would
>> actually become the first step towards the formal Shapes
>> declarations. In fact we could start to encode them as an RDF model
>> (e.g. SPIN templates) and try them out in real-time. We could
>> collectively edit a Turtle file and generate human-readable
>> documents from that.
>>
>> Holger
>>
>>

Received on Wednesday, 22 October 2014 23:53:18 UTC