Re: One example

Hi Karen,

attached is a SHACL version of your requirements. While I may of course 
have misunderstood some details, I believe the spirit is captured. Note 
that most constraints required SPARQL. There were a couple that cannot 
be expressed: those that make HTTP requests to look up resources and 
handle error codes. This would either require SPARQL extension functions 
or a language such as JavaScript.

I will present some of this in my presentation.

Regards,
Holger


On 5/18/2015 10:48, Karen Coyle wrote:
>
>
> On 5/17/15 4:00 PM, Holger Knublauch wrote:
>> Hi Karen,
>>
>> walking through the requirements there appear to be some duplicates
>> (apologies if I misunderstand them):
>
> Not entirely sure I understand it myself, so if we can't figure it out 
> I'll have to catch someone from Europeana who can help us. Note that 
> they do all of their work in XML, and currently validate using 
> Schematron. I'm sure this colors their view of the data. Note, too, 
> that the comments that are in the RDFXML are not carried forward to 
> the TTL, so it is probably best to read the requirements in the 
> context of the RDFXML file. Why don't we settle on one or two sets of 
> requirements, and I'll try to catch someone tomorrow who can clarify 
> the data more generally. The first one seems fairly simple:
>
>>
>> Duplicate 1:
>>
>>   * #1 For every CulturalHeritage object (CHO) the URI of the
>>     ProvidedCHO and the URI described in edm:aggregatedCHO must be 
>> the same
>>
>>   * #6 Each EDM CHO must have exactly one instance of rdf:type
>>     edm:ProvidedCHO and one instance of rdf:type ore:Aggregation
>>     (DC:R-225) (W3:R-6) (W3:R-12.2)
>
> The first one does not limit cardinality to "1", the second does. The 
> first checks that the subject URI's are the same:
>
>    <edm:ProvidedCHO 
> rdf:about="http://data.europeana.eu/item/09102/_CM_0159253"/>
>       <edm:aggregatedCHO 
> rdf:resource="http://data.europeana.eu/item/09102/_CM_0159253"/>
>
>
>>
>> Duplicate 2 (maybe subtle differences, hard to understand for me):
>>
>>   * #2 For every CHO or ore:Proxy dc:coverage or dc:subject or dc:type
>>     and dcterms:spatial; dc:language for text,dc:title or
>>     dc:description, must be present (DC:R-68) (W3:R-5.2)
>
> #2 isn't clear to me, so let's skip it for now.
>
>>   * #13 if edm:ProvidedCHO or ore:Proxy is present, at least one
>>     dc:title or dc:description should be present, one dc:subject or
>>     dc:type or dc:coverage or dcterms:spatial and edm:type should be
>>     present (DC:R-71) (W3:R-6) (W3:R-6.2) (W3:R-6.7)
>
> #13 seems to be almost clear:
>
> for each (edm:ProvidedCHO, ore:Proxy)
>    required: at least one dc:title or one dc:description [can it have 
> both? I'll ask]
>    required: at least one dc:subject or dc:type or dc:coverage or 
> dcterms:spatial [more than one of any? will ask]
>    required: edm:type
>
>>   * #14 For each edmProvidedCHO or ore:Proxy (provider proxy)
>>     dc:coverage or dc:subject or dc:type or dcterms:spatial,dc:language
>>     (for text objects), dc:title or dc:description or edm:type must be
>>     present (DC:R-67) (W3:R-6.2) (W3:R-6.7)
>
> For #14, I need to figure out what edm:type modifies, but we do know 
> that:
>     valid values for edm:type are: (VIDEO, SOUND, IMAGE, TEXT)
>
> For the rest, this is how far I've gotten:
>
> for each (edm:ProvidedCHO, ore:Proxy)
>     required: dc:coverage or dc:subject or dc:type or dcterms:spatial
>     if resource type is text, "<edm:type>TEXT</edm:type>") <!-- need 
> to discover how "resource type" is defined -->
>         required: dc:language, dc:title, dc:description or edm:type 
> <!-- which "or"? -->
>
>>
>> Duplicate 3:
>>
>>   * #3 We must have only one PrefLabel per language. Ideally the
>>     language tag should be present (DC:R 49) (W3:R-6.4)
>>   * #5 We must have only one PrefLabel per language. Ideally the
>>     language tag should be present (DC:R 49) ((W3:R-6.4)
>
> Those are within different graphs. I don't know if that matters in 
> your design, but one is in the graph <edm:Agent> (in the RDFXML), the 
> other in the graph <record>. But since we had to remove <record> 
> because it isn't defined, I'll have to come back with a corrected data 
> set for this one.
>
> In the TTL file, these show up as:
>
> <http://www.mimo-db.eu/InstrumentMaker/Person/2816>
>   rdf:type edm:Agent ;
>   dc:date "1767" ;
>   dc:identifier "#SMS-MM:N234546" ;
>   rdaGr2:dateOfBirth """c
> 1730""" ;
>   rdaGr2:dateOfDeath """p
> 1783""" ;
>   skos:prefLabel """Edmond
> Saunier""" ;
>   foaf:name """Saunier,
>       Edmond""" ;
> .
> <http://www.mimo-db.eu/InstrumentsKeywords/3510>
>   rdf:type skos:Concept ;
>   skos:broader <http://www.mimo-db.eu/InstrumentsKeywords/3509> ;
>   skos:prefLabel "Mandolin" ;
>   skos:prefLabel "Mandolin"@en ;
>   skos:prefLabel "Mandolin"@sv ;
>   skos:prefLabel "Mandoline"@de ;
>   skos:prefLabel "Mandoline"@fr ;
>   skos:prefLabel "Mandoline"@nl ;
>   skos:prefLabel "Mandolino"@it ;
> .
>
> In this case, I'm thinking that the skos:prefLabel rule can be 
> universal/general -- that it should apply wherever there is 
> skos:prefLabel. That would fit in with our use case 21 [1], and it's a 
> good candidate for a template/macro that would be of general use.
>
> kc
> [1] 
> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc21-skos-constraints
>
>>
>>
>> Some more questions:
>>
>> - For #8 "Check that the edm:hasView, edm:isShownBy and edm:object
>> resolves to a media", does this mean that the values of those properties
>> must have a certain rdf:type (e.g. edm:WebResource) or does it mean that
>> the system shall do a web look-up to check for a valid HTTP response?
>>
>> - The page at "#9 The value of edm:rights must come from the list at
>> http://pro.europeana.eu/web/available-rights-statements" only seems to
>> contain HTML - is there an RDF version that lists the valid values? How
>> else can this be checked?
>>
>> Thanks
>> Holger
>>
>>
>> On 5/17/2015 13:03, Karen Coyle wrote:
>>> OK, the example should work now -- at least, it passes validation in
>>> the RDF validator and rapper. It appears to have 3 "records" worth of
>>> data, so there are multiple "outer" graphs. If that's a problem, I can
>>> reduce it down to a single "outer" graph.
>>>
>>> kc
>>>
>>> On 5/16/15 7:20 PM, Karen Coyle wrote:
>>>> OK, I'll see if I can find anyone who can answer that, since this 
>>>> isn't
>>>> my data. I'm thinking there's something basic going wrong - such as 
>>>> the
>>>> software not finding the ontology.
>>>>
>>>> Meanwhile, here's the link to the latest version of the ontology:
>>>> https://github.com/europeana/corelib/blob/master/corelib-edm-definitions/src/main/resources/eu/rdf/edm-v524-130522.owl 
>>>>
>>>>
>>>>
>>>>
>>>> I'll try to get back to you soon.
>>>> kc
>>>>
>>>> On 5/16/15 5:05 PM, Holger Knublauch wrote:
>>>>> Also, the RDF/XML file
>>>>>
>>>>> http://kcoyle.net/temp/EDMvalidexamples.xml
>>>>>
>>>>> doesn't seem to be parse, and produces many errors, see
>>>>>
>>>>> http://www.w3.org/RDF/Validator/rdfval?URI=http%3A%2F%2Fkcoyle.net%2Ftemp%2FEDMvalidexamples.xml&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Holger
>>>>>
>>>>>
>>>>> On 5/17/2015 8:02, Karen Coyle wrote:
>>>>>> In case anyone wants a real example to work with, I have created a
>>>>>> short page that lists the requirements and the file of data those
>>>>>> requirements pertain to. The requirements themselves are also 
>>>>>> embedded
>>>>>> in the XML file so you can see what graph they are associated with.
>>>>>>
>>>>>> http://kcoyle.net/temp/EDMvalidReqs.html
>>>>>>
>>>>>> While it may be the case that no one wants to tackle this at this
>>>>>> time, it does include some common use cases. The list includes 
>>>>>> both DC
>>>>>> and SHACL requirements numbers, and links to the spreadsheet with DC
>>>>>> requirements, that then in turn links to further information.
>>>>>>
>>>>>> kc
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>