Re: Enumeration values

On 2015-01-10 14:17, Thomas Hoppe wrote:
> 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"
>    }
> ]
>

This is pretty much what though of initially but I don't we should use 
individuals in place of classes.

 >
> Or with properties from some domain specific vocab:
>
> "hydra:allowedIndividuals": [
>    {
>      "someVocab:eventStatus": "EventCancelled",
>      "rdfs:label": "manifestazione annullata"
>    },
>    {
>      "someVocab:eventStatus": "EventPostponed",
>      "rdfs:label": "manifestazione rinviata"
>    }
> ]
>

What purpose does using some other predicate here serve? Will it have to 
be same as the property described? What if it is not. I find this an 
unnecessary complication for the client.

> 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.
>

Ah yes, I like where this is going. I was myself about to write about a 
case where the individuals are filtered by the user. Think auto-complete 
<select /> as a common example.

How would it be possible to reuse (templated) links as an option for 
remote source of available individuals? Also would we restrict the 
response somehow to hydra:Collection?

Regards,
Tom

> 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 14:26:06 UTC