- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 16 Sep 2016 15:26:36 +1000
- To: public-rdf-shapes@w3.org
- Message-ID: <3ed047b1-b42a-ba8a-12f4-c1e351cfd5ca@topquadrant.com>
I think the broader topic that you are touching on is "literals as
subjects". If RDF would allow literals in the subject position of a
triple then people could write
"#FF0000" rdfs:label "red" .
I believe the RDF 1.1 WG had discussed this topic at length and decided
against literals as subjects. The alternative with the current RDF would
be to "reify" these colors into objects, e.g.
ex:Red
a ex:Color ;
rdfs:label "red" ;
ex:htmlColor "#FF0000" .
That would follow the standard practices in RDF.
I am not responding on behalf of the WG, but I would not be surprised if
the feeling is that we are too late in the process to add new
requirements here, and the sentiment may be that the vocabulary that you
suggest is not SHACL-specific enough and could therefore originate from
any 3rd party. Even in your own solution below there is no real
connection between the Shape and the ex:MyAnnotation node, so what is
SHACL-specific here that couldn't be solved elsewhere?
Regards,
Holger
On 15/09/2016 17:48, Miika Alonen wrote:
> This is turning into a monolog but here's one suggestion for
> documenting the semantics of the enumerations (sh:in values) in the
> SHAPE graph:
>
> ex:InExampleShape
> a sh:Shape ;
> sh:targetNode ex:RainbowPony ;
> sh:property [
> sh:predicate ex:htmlColor ;
> sh:in ('#FDD7E4' '#800080' ex:Whatever) ;
> ] .
>
> ex:MyAnnotation a sh:Annotation .
> ex:MyAnnotation sh:value "#FDD7E4" .
> ex:MyAnnotation sh:name "Pig Pink" .
> ex:MyAnnotation sh:description "Typical color of a pig" .
>
> ex:MyAnnotation2 a sh:Annotation .
> ex:MyAnnotation2 sh:value ex:Whatever .
> ex:MyAnnotation2 dcterms:description "For some reason this annotation
> includes additional metadata" .
> ...
>
> I really think that there should be a standard way to do this. If
> there is no way to document literal values in sh:in-list, those values
> will not be documented (or documented in various ways - which still is
> a serious pitfall). Including something like this to the specification
> should not be an issue because sh:Annotation (or whatever class name)
> would not be processed by the validators. Annotations would be used in
> other use cases - like general documentation or in form generation.
>
> - Miika
>
> ------------------------------------------------------------------------
> *From: *"Miika Alonen" <miika.alonen@csc.fi>
> *To: *"Dimitris Kontokostas" <kontokostas@informatik.uni-leipzig.de>
> *Cc: *"public-rdf-sha." <public-rdf-shapes@w3.org>
> *Sent: *Thursday, 15 September, 2016 09:45:21
> *Subject: *Re: Labels for literals in sh:in enumeration
>
> Hi,
>
> Here's another example. Consider you have some legacy XML data we want
> to transform to RDF. In that case we might have the schema for the XML:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:dcterms="http://purl.org/dc/terms/">
> <xs:element name="RainbowPony" type="RainbowPonyType"/>
> <xs:complexType name="RainbowPonyType">
> <xs:sequence>
> <xs:element name="HtmlColor">
> <xs:simpleType>
> <xs:restriction base="xs:string">
> <xs:enumeration value="#FDD7E4">
> <xs:annotation>
> <xs:documentation>
> <dcterms:title>Pig Pink</dcterms:title>
> </xs:documentation>
> </xs:annotation>
> </xs:enumeration>
> <xs:enumeration value="#800080'">
> <xs:annotation>
> <xs:documentation>
> <dcterms:title>Purple</dcterms:title>
> </xs:documentation>
> </xs:annotation>
> </xs:enumeration>
> </xs:restriction>
> </xs:simpleType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>
>
> And we want to create RDF representation for the data, say:
>
> _:n1 ex:htmlColor '#FDD7E4' .
>
> And for validating that we could then create a shape:
>
> ex:InExampleShape
> a sh:Shape ;
> sh:targetNode ex:RainbowPony ;
> sh:property [
> sh:predicate ex:htmlColor ;
> sh:in ('#FDD7E4' '#800080') ;
> ] .
>
> The issue was that this representation is missing the option to
> annotate the literal values. You can of course argue that the color
> representation should be a Resource: (color:Pink ex:htmlColor
> '#FDD7E4') but i dont think its reasonable to create resources for all
> literal values just that you can document those values in the schema.
>
> - Miika
>
> ------------------------------------------------------------------------
> *From: *"Miika Alonen" <miika.alonen@csc.fi>
> *To: *"Dimitris Kontokostas" <kontokostas@informatik.uni-leipzig.de>
> *Cc: *"public-rdf-sha." <public-rdf-shapes@w3.org>
> *Sent: *Wednesday, 14 September, 2016 12:06:15
> *Subject: *Re: Labels for literals in sh:in enumeration
>
> Hi,
>
> Listing the values and labels to the same list, for example:
>
> sh:in ('#FDD7E4
> <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=FDD7E4>' 'Pig
> Pink' '#800080
> <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=800080>' 'Purple');
>
> would mean that 'Pig Pink' and 'Purple' are also a valid values for
> the predicate. This would be very odd and not very explicit if you
> dont know what to expect from the enumerations.
>
> All i can think of (without adding something to the SHACL syntax)
> would be to include labels to separate resources describing the literals:
>
> _:x1 rdf:value '#FDD7E4' .
> _:x1 rdfs:label 'Pig Pink'@en .
> _:x1 rdfs:label 'Vaaleanpunainen'@fi .
>
> ... but then the labels would be kind of off the specification that
> wouldnt support generic form generation.
>
> - 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: *Wednesday, 14 September, 2016 10:40:56
> *Subject: *Re: Labels for literals in sh:in enumeration
>
> Hello Miika,
> you can have it like
> sh:in ( 1 333 true "string" "lang string"@en "2"^^xsd:unsignedInteger
> ex:A )
> and SHACL will check if your value is in this list
>
> if your rdf nodes in the sh:in list are valid, i.e. there is no
> "a"^^xsd:int SHACL engnes (the ones based on SPARQL at least) will
> work correctly
>
> On Wed, Sep 14, 2016 at 9:01 AM, Miika Alonen <miika.alonen@csc.fi
> <mailto:miika.alonen@csc.fi>> wrote:
>
> Hi all,
>
> What would be the best way to include labels to sh:in for
> literals? Using literals instead of resources is reasonable in
> some use cases.
>
> For example you might want to use literals for HTML colors and
> labels for the drop down menu:
>
> ex:InExampleShape
> a sh:Shape ;
> sh:targetNode ex:RainbowPony ;
> sh:property [
> sh:predicate ex:htmlColor ;
> sh:in ('#FDD7E4 <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=FDD7E4>''#800080 <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=800080>') ;
> ] .
>
> instead of:
>
>
> sh:in ( ex:Pink ex:Purple ) ...
> ... and something like ... ex:Pink rdf:value '#FDD7E4 <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=FDD7E4>' .
>
> There is of course many ways to model this but in case you need to
> use literals for simplicity the could be something like enumNames
> that is proposed to JSON Schema v5:
> https://github.com/json-schema/json-schema/wiki/enumNames-(v5-proposal)
> <https://github.com/json-schema/json-schema/wiki/enumNames-%28v5-proposal%29>
>
> Best Regards,
> Miika Alonen
>
> CSC - IT Center for Science
> miika.alonen@csc.fi <mailto:miika.alonen@csc.fi>
>
>
>
>
> --
> 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 Friday, 16 September 2016 05:27:09 UTC