W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

Re: Enumeration values

From: Dietrich Schulten <ds@escalon.de>
Date: Sat, 10 Jan 2015 07:51:18 +0100
Message-ID: <54B0CBE6.6060406@escalon.de>
To: public-hydra@w3.org
In order to get internationalized captions for allowed individuals one 
could do the following. If :allowedIndividuals is expected to contain 
objects with an attribute :allowedIndividual (:allowedIndividuals :range 
:AllowedIndividual), one can use that with "@type":"vocab" to interpret 
the values as individuals in the default vocab, here enum values in 
schema.org (see below and [1]).

Drawback: If someone just wants enum values without captions, things are 
more complicated than necessary.


Assuming that the client requested Italian as language (the other 
language facilities of json ld such as @language or language map would 
work, too [2]).

   "@context": {
     "@vocab": "http://schema.org/",
     "hydra": "http://www.w3.org/ns/hydra/core#",
     "hydra:allowedIndividual": {
       "@type": "@vocab"
         "hydra:supportedProperty": [
             "hydra:property": "eventStatus",
             "hydra:allowedIndividuals": [
                 "hydra:allowedIndividual": "EventCancelled",
                 "hydra:title": "manifestazione annullata"
                 "hydra:allowedIndividual": "EventPostponed",
                 "hydra:title": "manifestazione rinviata"

In JSONLD-Playground:
[1] http://tinyurl.com/qz85ep6
[2] http://tinyurl.com/om7fsqc

Am 09.01.2015 um 18:03 schrieb Dietrich Schulten:
> I was considering to use oslc:allowedValue in hydra-java but wasn't 
> sure if I could use it because its value is explicitly a reference to 
> another class, not an embeddable restriction - and I need it in 
> embedded form for the moment.
> I see the label-value problem, too. I'll try to make it work with 
> @type:vocab.
> On January 9, 2015 5:17:38 PM Kev Kirkland <kev@dataunity.org> wrote:
>> Just to chime in - I agree also.
>> I've implemented the 'oslc:allowedValue' system from Resource Shape 
>> 2.0 [1] in the AngularJS Hydra client [2]. It's a stop gap solution 
>> as I needed something working in a hurry for Data Unity. I went with 
>> OSLC as it was quick to understand and implement, but I'm very open 
>> minded about other solutions.
>> One of the issues I've found with 'oslc:allowedValue' is that I can't 
>> find a way to specify a label for an RDF literal 'enum' value. This 
>> means the label in the HTML option list matches the literal value 
>> used in the vocab, which isn't always easily understood by the user. 
>> This could well be down to my lack of understanding about OSLC though.
>> I've only put 'oslc:allowedValue' directly on the resource 
>> representation at this stage, so I haven't figured out how to 
>> integrate it closely with Hydra. The AngularJS Hydra client looks for 
>> OSLC information on the Resource when building the Form view, then 
>> uses it to populate HTML drop downs on the page.
>> Cheers,
>> Kev
>> [1] http://www.w3.org/Submission/2014/SUBM-shapes-20140211/
>> [2] https://github.com/dataunity/dataunity-hydra-client
>> On 9 January 2015 at 15:23, Thomas Hoppe <thomas.hoppe@n-fuse.de 
>> <mailto:thomas.hoppe@n-fuse.de>> wrote:
>>     Hi,
>>     I just wanted to add that I consider the case Dietrich is describing;
>>     in my own words:
>>     Specifying expected properties _plus_ a range/ resource/
>>     collection/ enumeration
>>     of potential values a very important one.
>>     Ex: User profile creation case where you ask for the country of
>>     residence of a user and expect an item from a resource in the
>>     same API as value.
>>     I wanted to bring up this case earlier but wanted to wait until
>>     we have resolved the
>>     "easy" scenarios.
>>     I also think that OWL restrictions are probably too hard to
>>     understand/ implement
>>     and that only because of this I think that having a property like
>>     `hydra:range`
>>     could make sense.
>>     Greets, Thomas
>>     On 01/06/2015 12:21 PM, Dietrich Schulten wrote:
>>>     -----BEGIN PGP SIGNED MESSAGE-----
>>>     Hash: SHA1
>>>     Am 05.01.2015 um 11:15 schrieb Ruben Verborgh:
>>>>     HI Dietrich,
>>>>     [From issue text:]
>>>>>>     Isn't that part of ontological modelling, and thus
>>>>>>     part of the
>>>>>>     property?
>>>>>     I do not think the ontological model of a property covers it.
>>>>     Perhaps not all cases, but I think for many.
>>>>>     On the one hand, sometimes not all possible values are
>>>>>     predefined, but they may be extensible by individuals from other
>>>>>     vocabs, see the usage of goodrelations enums fromschema.org  <http://schema.org>.
>>>>     In that case, you might have a more specific property. (But I
>>>>     realize this modeling-based solution is not for everybody.)
>>>     What about the other hand [from issue text]?
>>>>>     On the other hand, while a value might occur on a class in
>>>>>     general,
>>>     it might not be suitable in a particular context.
>>>     For instance, assume that only the creator of an event should be able
>>>     to cancel it altogether (PUT eventStatus EventCanceled), others can
>>>     only change the status to rescheduled or postponed. Or, let's say it
>>>     should only be possible to reschedule an event as long as we are more
>>>     than two weeks away from the event date.
>>>     As a REST service implementor I would like to tell the client exactly
>>>     which status changes are available for a resource right now.
>>>     Are there OWL constructs which would allow me to do so?
>>>     BTW, the Resource Shapes paper [1] section 4 discusses another point
>>>     why OWL is not well suited to describe application constraints. As
>>>     they put it, "Unfortunately, an OWL reasoner will go to great lengths
>>>     to make some superficially inconsistent looking graphs consistent". By
>>>     saying that a property :owner is a :functionalProperty of a
>>>     :ChangeRequest, I do not prevent people to post a ChangeRequest with
>>>     two owners :Bob and :Joe. A reasoner would simply infer that :Bob and
>>>     :Joe must be the same resource and happily accept the change request.
>>>>>     If you think rdfs:range, it is not about value constraints but
>>>>>     inference, so it doesn't enumerate possible values at all (I've
>>>>>     learned that much by now). Or do you have something else in
>>>>>     mind?
>>>>     OWL does it. I understand most people don't want to go that
>>>>     “complex” (even though it's quite alright), but we should just be
>>>>     aware that a modeling-based solution also exists.
>>>     And it would have the beauty that it is already available and the
>>>     concepts are known, at least by modelers. I would certainly prefer
>>>     that over defining new hydra properties.
>>>     What do you have in mind, maybe owl:Restriction?
>>>>     For example: foaf:knows has a range of foaf:Person. If we're
>>>>     developing a social application, it might make sense to restrict
>>>>     this to only people on the network. Yet listing them exhaustively
>>>>     would probably not make sense. So then perhaps a ex:knows
>>>>     (subproperty of foaf:knows) where the range is “people from the
>>>>     network” makes sense.
>>>     But how can I express a Range "people from the
>>>     network", given that
>>>     the number of people on the network is dynamic? You bring up an
>>>     interesting point. A ReST service would also want to tell the client:
>>>     use this link (or IriTemplate) to get a hydra:Collection of allowed
>>>     values. A third property hydra:allowedResources which may contain an
>>>     IriTemplate or a plain Resource which can be dereferenced into a
>>>     Collection or PagedCollection could achieve that. I'll update #82
>>>     accordingly [2] and see which comments I get :)
>>>     The  original purpose of #82 is to have a means to list a rather
>>>     limited number of possible values and to leverage @type:@vocab for
>>>     enumerated values likehttp://schema.org/DeliveryMethod  which has
>>>     members from goodrelations.
>>>     [1]http://events.linkeddata.org/ldow2013/papers/ldow2013-paper-02.pdf
>>>     [2]https://github.com/HydraCG/Specifications/issues/82
>>>     - -- 
>>>     Dietrich Schulten
>>>     Escalon System-Entwicklung
>>>     Bubenhalde 10
>>>     74199 Untergruppenbach
>>>     -----BEGIN PGP SIGNATURE-----
>>>     Version: GnuPG v2.0.22 (MingW32)
>>>     iEYEARECAAYFAlSrxUcACgkQuKLNitGfiZP6PgCgts8wESKTDz3atmXofBPheWTt
>>>     ACAAn2S9kUWiUwpgZUd/cPXnDujw00ib
>>>     =z5B1
>>>     -----END PGP SIGNATURE-----
>> -- 
>> www.dataunity.org <http://www.dataunity.org>
>> twitter: @data_unity
Received on Saturday, 10 January 2015 06:51:59 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 10 January 2015 06:51:59 UTC