Re: Enumeration values

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