Hi all,

Just a follow up on my last email.

Since then, I have removed all redundant minimum cardinalities... actually, the reason why I had created them in the first place was because of the shape closure (which was picking up the property from the constraint) but I opted now to place all acceptable properties directly in the closure constraint (even if there is already a constraint for it). I have also added the link to SHACL template library that I have created where I define functions to meet requirements that are natively supported by SHACL functions. One of such functions is a disjointness function which is being used within the skos:Concept shape. Also, added more tests which will continue on during the next weeks.

It is all for now...

Best regards, Hugo

________________________________________
From: DCMI Architecture Forum [[log in to unmask]] on behalf of Antoine Isaac [[log in to unmask]]
Sent: 08 April 2016 11:36
To: [log in to unmask]
Subject: Re: [RDF-AP] Sharing progress on SHACL validation at Europeana

Hi Karen,

I'm not a great fan of specifying 'empty' constraints like min=0 or max=unlimited. But if there's a max defined, then if someone wants to add min=0 to 'round the definition' I don't have a strong objection to it. But if the implementer doesn't want to set a max then this should also be allowed. And if both constraints are not informative (i.e. min=0 or max=unlimited) then leaving them both off seems preferable to me, indeed!

Antoine

On 4/7/16 6:59 PM, Karen Coyle wrote:
> Here's the thing with min and max counts: if you leave them off, then the result is min=0, max=unlimited. However, you cannot specify "max=unlimited" using SHACL, since the value of min and max must be an integer. I think this is too bad because including them makes the cardinality choice more visible. However, since they aren't symmetrical, it probably does make sense to leave both off. Personally, if maxCount were being defined I would probably also expect to see minCount even if minCount=0. This is something to think about in terms of best practices, not so much for validation but for clarity of the documentation function.
>
> kc
>
> On 4/7/16 6:59 AM, Antoine Isaac wrote:
>> Hi Hugo,
>>
>> Thanks for sharing that impressive work!
>>
>> Two quick comments/questions, which may help others to read the material
>> (if you simplify the data shown there)
>>
>> - why would I have to see all these cardinality shapes where the min
>> cardinality is 0? This carries absolutely no new information to me.
>> I'd suggest to remove all the 'mincount 0' statements. And to remove the
>> shapes that only have such statements.
>>
>> - dc:subject doesn't fit very well for the link between a shape and a
>> requirement. I'd just go for dc:related for the time being. So that we
>> don't focus too much on discussing the nature of this link for now :-)
>>
>> Antoine
>>
>> On 4/7/16 2:06 PM, Hugo Manguinhas wrote:
>>> Dear all,
>>>
>>> We have made some significant progress on the Europeana side on using
>>> SHACL for EDM validation… I will give a short explanation of what I
>>> did in this email, but all information can also be accessed in my
>>> GitHub account at this page [1] which explains all the work done so
>>> far and has all the pointers for the different parts of the work and
>>> related resources.
>>>
>>> First of all, we have finished defining all constraints for all EDM
>>> classes. When I shared it for the first time, we had only implemented
>>> the constraints for edm:ProvidedCHO, but know it is complete… (also a
>>> note that all shapes are now defined as closed shapes). However, it
>>> may still suffer some changes in the coming days. Btw, I have created
>>> a section on the main page [1] with my experience using SHACL
>>> explaining the limitations and possible improvements.
>>>
>>> The first part that I have implemented corresponds to a more palatable
>>> view [2] (I had shared in our last call a draft version of it) of the
>>> shapes definitions which are defined in Turtle syntax. I had initially
>>> created it to help myself, so that I could make sure that everything
>>> was being linked and defined correctly (unfortunately, the Java
>>> implementation does not complain when I make mistakes), with correct
>>> IDs, complete metadata, but quickly proved to be a much more
>>> interesting way to view, navigate and manage the definitions.
>>>
>>> I have also created some test suites (here is an example [3] just for
>>> resources of type edm:Agent) for each of the EDM classes that helped
>>> me confirm the outputs of validation and make the necessary
>>> adjustments so that the output fits what we expect/need. This was also
>>> something that we had discussed on past meetings.
>>>
>>> Finally, we have started to think of how a report (here is an example
>>> [4] for the dataset we are currently using for semantic enrichment) of
>>> a validation over a complete dataset would look like. Several reports
>>> may be generated from a raw validation output, but this is just a
>>> glimpse.
>>>
>>> Looking forward for this call... and sorry sharing it so close to our
>>> call.
>>>
>>> References:
>>> [1]
>>> https://github.com/hugomanguinhas/europeana_shapes/tree/master/shapes-edm/doc/shapes
>>>
>>> [2]
>>> https://github.com/hugomanguinhas/europeana_shapes/blob/master/shapes-edm/doc/shapes/Agent.md
>>>
>>> [3]
>>> https://github.com/hugomanguinhas/europeana_shapes/blob/master/shapes-edm/doc/tests/Agent.md
>>>
>>> [4]
>>> https://github.com/hugomanguinhas/europeana_shapes/blob/master/shapes-edm/doc/reports/DBpediaAgents.md
>>>
>>>
>>> Kind regards,
>>>
>>> *Hugo Manguinhas*
>>>
>>> Technical R&D Coordinator
>>>
>>> T: +31 (0)70 314 0998
>>> M:
>>> E: [log in to unmask]
>>>
>>> Skype: hugo.manguinhas
>>>
>>> *Be part of Europe's online cultural movement - join the Europeana
>>> Network Association: http://bit.ly/NetworkAssociation*
>>>
>>>
>>> ***#AllezCulture!*
>>>
>>> Disclaimer: This email and any files transmitted with it are
>>> confidential and intended solely for the use of the individual or
>>> entity to whom they are addressed. If you have received this email in
>>> error please notify the system manager. If you are not the named
>>> addressee you should not disseminate, distribute or copy this email.
>>> Please notify the sender immediately by email if you have received
>>> this email by mistake and delete this email from your system.
>>>
>>
>