W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

Re: Validating instances based on other instances

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Tue, 27 Sep 2016 09:18:03 +0300
Message-ID: <CA+u4+a03ap-Gr+mHNpY2wJx+JD89HmBkvwYCUEP5-W=3ert2UA@mail.gmail.com>
To: Miika Alonen <miika.alonen@csc.fi>
Cc: "public-rdf-sha." <public-rdf-shapes@w3.org>
A minor adjustment / property swap
ex:A a sh:Shape ;
  sh:targetObjectsOf *ex:related* ;
  sh:property [
    sh:path [ sh:inversePath *ex:identifier* ]
    sh:minCount 1;
  ]

this shape would report

"12.123/example.1234" -> valid
"20.234/undefined.2234" -> invalid
"null" -> invalid

On Tue, Sep 27, 2016 at 8:42 AM, Miika Alonen <miika.alonen@csc.fi> wrote:

> I dont see how that would work. There can also be multiple Datasets and
> Documents are expected have references to non existing datasets eg:
>
> ex:Dataset1 ex:identifier "12.123/example.1234" .
> ex:Dataset2 ex:identifier "12.1234/example.2345" .
> ex:Dataset3 ex:identifier "12.123/example.4321" .
>
> ex:Document1 ex:related "12.123/example.1234" .
> ex:Document1 ex:related "20.234/undefined.2234" .
> ex:Document1 ex:related "null" .
>
> This again is example of "bad" data that could be cleaned - but there are
> many use cases where resources are "linked" using literal references.
>
> - Miika
>
> ------------------------------
> *From: *"Dimitris Kontokostas" <kontokostas@informatik.uni-leipzig.de>
> *To: *"Miika Alonen" <miika.alonen@csc.fi>
> *Cc: *"public-rdf-sha." <public-rdf-shapes@w3.org>
> *Sent: *Monday, 26 September, 2016 22:20:25
> *Subject: *Re: Validating instances based on other instances
>
> Hi Miika,
> a workaround could be something like
> ex:A a sh:Shape ;
>   sh:targetObjectsOf ex:identifier ;
>   sh:property [
>     sh:path [ sh:inversePath ex:related ]
>     sh:minCount 1;
>   ]
>
> On Mon, Sep 26, 2016 at 6:34 PM, Miika Alonen <miika.alonen@csc.fi> wrote:
>
>> Hi all,
>>
>> Question about how to validate instance literals (or irirefs) based on
>> other instance values.
>>
>> I have a use case where i have literals that should be same as some other
>> literals, for example:
>>
>> VALID DATA:
>>
>> ex:Dataset ex:identifier "doi:10.3972/example.0145.db" .
>>
>> ex:Document ex:related "doi:10.3972/example.0145.db" .
>>
>>
>> INVALID DATA:
>>
>> ex:Dataset ex:identifier "doi:10.3972/example.0145.db" .
>>
>> ex:Document ex:related "doi:null" .
>>
>>
>> Is there other ways to validate this than Sparql constraints. I know i
>> could do something like:
>>
>> <http://example.com/ns#> sh:prefix "ex" .
>>
>> ex:DocumentShape
>>     a sh:Shape ;
>>     sh:targetClass ex:DocumentType ;
>>     sh:sparql [
>>         sh:message "Values must be dataset identifiers" ;
>>         sh:select """
>>             SELECT $this ?value
>>             WHERE {
>>                 $this ex:related ?value .
>>                                 ?identifier ex:identifier ?value .
>>             }
>>             """ ;
>>     ] .
>>
>> ETC ... but sparql seems bit overkill and it is hard to write. Is there
>> or could there be other ways to produce these queries? For example property
>> paths where first resource would be the starting point of the property
>> path, eg:
>>
>> sh:DocumentShape
>>       a sh:Shape .
>>       sh:targetClass ex:DocumentType ;
>>       sh:property [
>>         sh:predicate ex:related ;
>>         sh:equals ( ex:DatasetType ex:identifier );
>>     ] .
>>
>>
>> - Miika
>>
>
>
>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia
> Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Tuesday, 27 September 2016 06:19:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:44 UTC