Re: RDF Data Shapes WG agenda for 12 February 2015

I'll throw another wrench Eric's way: if this is a primer, it has way 
too much code and not enough explanatory text. Anything given in 
examples must be fully explained in text first as a more general case. 
Examples then show a single instance of the general case. The reader 
should not have to make the generalization himself/herself. The RDF 
Primer (original or 1.1) is a good example of what a primer should be, IMO.

kc
p.s. Yes, I'm willing to suggest text or areas for text, but I couldn't 
do so from what is there.

On 2/11/15 2:59 PM, Holger Knublauch wrote:
> Hi Eric,
>
> I have seen that Arnaud wants to have a straw poll on your version of the Primer tomorrow. Here are some of the outstanding issues from my perspective, and I can't vote until these are resolved.
>
> - A decision needs to be made whether we need a primer at all.
>
> - If this is a Primer then it needs to be complete: spawning off details about templates and SPARQL may go into a separate document of the core specification, but not of the primer. So the outsourced
> parts should be brought back for now.
>
> - The extension syntax is way too verbose, and should just be a single property such as ldom:sparql like before.
>
> - 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.
> Overall the union stuff is not all that interesting to deserve its
> own section IMHO. Union scenarios can easily also be represented
> in SPARQL.
>
> - The abstract starts off calling LDOM a "Grammar". I would prefer "RDF vocabulary".
>
> - LDOM templates currently do not handle multiple values. The
> enumeration example with allowed values should switch to an rdf:List
> for now:
>
> ldom:allowedValue  (ex:unassigned  ,ex:assigned)
>
> as it will be easier to support rdf:List-valued properties than
> multiple property values (then the SPARQL query can walk the
> rdf:List).
>
> - Due to the aforementioned complications, why not just remove the
> ldom:allowedValue altogether - it does not contribute much, or
> replace it with a pointer to a class such as ex:IssueStatus that has
> those two instances (a more extensible design anyway).
>
> - 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.
>
> - Section 6: "LDOM's extension mechanism permits other languages, like SPARQL, to be used when LDOM's expressivity is insufficient." makes no sense to me. LDOM includes SPARQL. Could be changed along the lines of "... when the expressivity of the pre-defined LDOM core templates is not sufficient.  But first we need to clarify what we mean with "core" and "extension".
>
> Thanks,
> Holger
>
>
>
> On 2/11/2015 14:23, Arnaud Le Hors wrote:
>> The agenda for the call on Thursday is now available:
>> http://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.02.12
>>
>> Note that I have carried over the proposal to approve a batch of
>> requirements that have now been renamed to address Peter's objection
>> and added another one. I hope we can close on this this week so,
>> please, come prepared.
>>
>> Thanks.
>> --
>> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards -
>> IBM Software Group
>

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

Received on Thursday, 12 February 2015 00:01:37 UTC