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

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?

>
> - 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.

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:42:25 UTC