- From: Dietrich Schulten <ds@escalon.de>
- Date: Sat, 10 Jan 2015 07:51:18 +0100
- To: public-hydra@w3.org
- Message-ID: <54B0CBE6.6060406@escalon.de>
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
>> <mailto: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 fromschema.org <http://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 likehttp://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 <http://www.dataunity.org>
>> twitter: @data_unity
Received on Saturday, 10 January 2015 06:51:59 UTC