Re: Enumeration values

Am 10.01.2015 um 08:32 schrieb tomasz@t-code.pl:
> Hi Dietrich,
>
> I don't like the duplicate hydra:allowedIndividual(s) property. using @type seems intuitive but I guess we don't to have an individual used as a class. So how about simply "hydra:individual"? This would be more in line with supportedProperty/property pair.

Good reasoning. I found the duplication also a bit clumsy. Based on your 
feedback I will update #82.

> Also do we already have the hydra:title defined? If not I'd simply used rdfs:label.

we have hydra:title

>
> {
>    "@type": "Property",
>    "hydra:allowedIndividual": [
>    { "hydra:individual": "EventCancelled", "rdfs:label": "..." },
>    { "hydra:individual": "EventPostponed", "rdfs:label": "..." }
>    ]
> }
>
> Tom
>
> January 10 2015 7:52 AM, "Dietrich Schulten" <ds@escalon.de> 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> 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 from 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 like http://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 twitter: @data_unity

Received on Saturday, 10 January 2015 12:05:45 UTC