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

Re: Enumeration values

From: Thomas Hoppe <thomas.hoppe@n-fuse.de>
Date: Sat, 10 Jan 2015 14:17:17 +0100
Message-ID: <54B1265D.2000403@n-fuse.de>
To: public-hydra@w3.org
Hi,

I don't see why we would need `hydra:allowedIndividual`. I have 
something easier in mind:
I would just enumerate the allowed individuals inline as they are.
The API client knows only from the fact that the individuals are 
declared as `hydra:allowedIndividuals`
that they make up the range of selection items from which it (or a user) 
can choose.
The client could then look for usual properties like `rdfs:label` to 
present them to a user.
In that case also all RDF/ JSON-LD mechanisms for localization would 
kick in as well.

With inline enumeration:

"hydra:allowedIndividuals": [
   {
     "@id": "EventCancelled",
     "rdfs:label": "manifestazione annullata"
   },
   {
     "@id": "EventPostponed",
     "rdfs:label": "manifestazione rinviata"
   }
]

Or with properties from some domain specific vocab:

"hydra:allowedIndividuals": [
   {
     "someVocab:eventStatus": "EventCancelled",
     "rdfs:label": "manifestazione annullata"
   },
   {
     "someVocab:eventStatus": "EventPostponed",
     "rdfs:label": "manifestazione rinviata"
   }
]

Also I want to stress again that we also need
to be able to link to some external resource:

"hydra:allowedIndividuals": {
   "@id": "https://example.com/event_status/"
}

This could be a normal API resource, a hydra collection probably.
But also in this case, It would be awkward if every item in this collection
would need to have an `hydra:allowedIndividual` property.

Greets, Thomas


On 01/10/2015 07:51 AM, Dietrich Schulten wrote:
> 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.
>
> Opinions?
>
> 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 13:17:49 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 10 January 2015 13:17:49 UTC