Re: Enumeration values

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