Re: Enumeration values

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