Re: RDF Data Shapes WG agenda for 12 February 2015

On 2/13/2015 0:31, Eric Prud'hommeaux wrote:
> Why are the rules different for a primer? Editorially, it seems 
> sensible to have a primer about the core spec and another about the 
> integration with SPARQL.

If your goal is to hide away the SPARQL features as much as possible 
then yes. If your goal is to give a succinct introduction into what the 
technology can do for you then a single document sounds better. All 
specs that I know seem to only have a single Primer document.

Anyway, I currently believe we shouldn't write a Primer at all, unless 
we can agree on a clear message towards the class-vs-shape discussion.

>
>
>> - The extension syntax is way too verbose, and should just be a single property such as ldom:sparql like before.
> I've added a swith in some issue text that switches between a SPARQL
> builtin ('b') vs. an extension model ('e') so folks can see both.

I cannot think of a single advantage of

ldom:constraint [
     ...
     ldom:extension [
       ldom:langauge <http://www.w3.org/Submission/spin-overview/> ;
       ldom:action """
       ASK {
         ?this ex:reportedOn ?submDt .
         ?this ex:assignedOn ?assnDt .
         FILTER (?submDt != ?assnDt) .
       }
       """ ]
   ] .

compared to

ldom:constraint [
     ...
    ldom:sparql """
       ASK {
         ?this ex:reportedOn ?submDt .
         ?this ex:assignedOn ?assnDt .
         FILTER (?submDt != ?assnDt) .
       }
       """ ]
   ] .

If your goal is to discourage the use of SPARQL as much as possible then 
yes, option 1 is best. If you want to produce something useable then 
option 2 is better.

(and definitely not "SPIN" anywhere there, no matter how much I love 
that name).

>
>
>> - The union syntax does not align with the concept of templates.
>> What was the problem with the old syntax? Introducing things like
>> ldom:propertyGroup looks unnecessary - just use another ldom:Shape.
> The object of ldom:propertyGroup is indeed a ldom:Shape with
> ldom:property arcs as you'd expect.

The issue remains that this syntax does not align with LDOM templates 
that are used everywhere else. The old syntax did a better job in this 
respect.

>
>
>> Overall the union stuff is not all that interesting to deserve its
>> own section IMHO. Union scenarios can easily also be represented
>> in SPARQL.
> I've never seen a schema language without OR before. I know I have
> lots of use cases where I need it in the core vocabulary. I've added
> text capturing this issue.
> [[
> <p class="issue">
>    Disjunction (the choice construct described below) is not an accepted requirement of LDOM.
> </p>
> ]]

I didn't say that, so I have removed that sentence. I only said that I 
don't think this is relevant enough to have its own syntax and its own 
section in the Primer. But the latter is less critical than the former - 
it's just a primer after all.

>
>> - It is unclear which of the URIs in Section 5 such as ldom:nodeShape are part of the standard. This comes back to the ShapeSelectors topic.
> The following paragraph says
> [[
> LDOM defines two predicates, ldom:nodeShape and ldom:classShape. The
> former asserts that a particular node in some graph conforms to a
> specific shape. The latter asserts that every node of some type
> conforms to a specific shape. It is expected that different
> communities will develop many more associations, much as the WSDL
> community created an association between input and output documents
> and an XML schema which described them.
> ]]

Let's revisit this when we have better bandwidth (at F2F).

Thanks
Holger

Received on Thursday, 12 February 2015 23:03:38 UTC