Re: Enumeration values

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

Received on Tuesday, 6 January 2015 11:22:19 UTC