Re: shapes-ACTION-48: Produce a json-ld @context draft

On 9/03/2017 17:41, Pano Maria wrote:
> Hi Holger,
>
>> Thanks a lot, Pano! Looks great so far. I will look deeper into this, but some quick feedback:
> Thanks!
>
>> - sh:focusNode and sh:targetNode can both carry either resources or literals. So I am afraid we cannot assume they are "@id" typed. Note that sh:focusNode is never entered directly but always machine-generated, so we don't need to worry about it, yet for sh:targetNode we need to keep it general.
> OK, I'll remedy this.
>
>> - Is it worth/possible to limit sh:minCount and the other xsd:integer properties to xsd:integer, so that either "1" or 1 can be used?
> Yes, the current style is limited. I'll add those as well.
>
>> - handling of sh:sourceConstraint is correct although it's never entered by a user.
> In that case, should we take it out of the @context?
> Is it ever returned as a property of a validation result?

Yes, but it is used by SHACL-SPARQL only. I think it can be deleted from 
the @context.

>
>> - Language maps look great for values that actually have a language, yet if this means that the syntax becomes inconsistent for those values that are plain xsd:strings, then I'd rather not use them. At this stage it's unclear how many people will use i18n values there anyway. Those that do can still add the @language tag for their local use. Having said this, further down you show how to use an alias ("pathList"), so maybe we could use "name" for sh:name and "names" for the lingual values?
> Exactly, the inconsistence is problematic. My current thinking is to
> keep it out, since it might be confusing to have both sh:name and
> sh:names. We could add some examples of potentially useful @context
> constructs, for those interested.

Ok.

Holger


>
> On Wed, Mar 8, 2017 at 5:36 AM, Holger Knublauch <holger@topquadrant.com> wrote:
>> Thanks a lot, Pano! Looks great so far. I will look deeper into this, but
>> some quick feedback:
>>
>> - sh:focusNode and sh:targetNode can both carry either resources or
>> literals. So I am afraid we cannot assume they are "@id" typed. Note that
>> sh:focusNode is never entered directly but always machine-generated, so we
>> don't need to worry about it, yet for sh:targetNode we need to keep it
>> general.
>>
>> - Is it worth/possible to limit sh:minCount and the other xsd:integer
>> properties to xsd:integer, so that either "1" or 1 can be used?
>>
>> - handling of sh:sourceConstraint is correct although it's never entered by
>> a user.
>>
>> - Language maps look great for values that actually have a language, yet if
>> this means that the syntax becomes inconsistent for those values that are
>> plain xsd:strings, then I'd rather not use them. At this stage it's unclear
>> how many people will use i18n values there anyway. Those that do can still
>> add the @language tag for their local use. Having said this, further down
>> you show how to use an alias ("pathList"), so maybe we could use "name" for
>> sh:name and "names" for the lingual values?
>>
>> Holger
>>
>>
>>
>>
>>
>> On 7/03/2017 19:52, Pano Maria wrote:
>>> I submitted a PR (https://github.com/w3c/data-shapes/pull/30) with a
>>> json-ld @context draft, including some examples. If time permits, we
>>> could discuss it Wednesday.
>>>
>>> Kind regards,
>>> Pano
>>>
>>> On Wed, Feb 15, 2017 at 3:02 PM, RDF Data Shapes Working Group Issue
>>> Tracker <sysbot+tracker@w3.org> wrote:
>>>> shapes-ACTION-48: Produce a json-ld @context draft
>>>>
>>>> http://www.w3.org/2014/data-shapes/track/actions/48
>>>>
>>>> Assigned to: Simon Steyskal
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>

Received on Thursday, 9 March 2017 07:48:02 UTC