Re: RDF Data Shapes WG agenda for 12 February 2015

Thanks, Eric. This does help, and I hope that more exposition of this 
type can be added throughout. (I'll do another read-through and note 
places where I think the document takes unexplained "leaps".) I'm still 
not sure that this document is a "primer" but perhaps we should agree on 
the content first and then discuss what documents we will provide, and 
for which audiences. In my mind a primer needs to function well as the 
very first document that a reader encounters about the standard, and it 
needs to answer questions like:  why is this standard necessary? what 
functions does it address? etc. Some of the technical detail in this 
document might be better situated in the language standard document.

I may have missed this, but do we have an ontology for LDOM?

kc


On 2/12/15 2:32 AM, Eric Prud'hommeaux wrote:
> * Karen Coyle <kcoyle@kcoyle.net> [2015-02-11 16:01-0800]
>> 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.
>
> I've added a couple paragraphs that I hope will address this. It calls
> out "shapes", "target nodes" (a node in a graph you're describing),
> "property constraints" (how many of which predicate look like what)
> and a couple other things.
>
> http://w3c.github.io/data-shapes/data-shapes-primer/no-class-templates.html#h-shapes
>
> So far, I've avoided talking about "validation" 'cause I fear that
> folks will say "it's not just for validation". We could go the other
> way and say "Shapes describe matching RDF graphs. We describe this in
> terms of validation but these descriptions can be used for other
> purposes like data and query service description or interface
> generation." Thoughts?
>
>
>> 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
>>
>

-- 
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 14:39:42 UTC