Re: Nested supportedProperty

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Am 16.12.2014 um 23:16 schrieb Markus Lanthaler:
> Thanks a lot for the update Holger. Much appreciated!
> 
> On 15 Dez 2014 at 00:09, Holger Knublauch wrote:
>> On 12/15/2014 5:44, Markus Lanthaler wrote:
>>> At the moment we can't really. We need to find a solution for
>>> this or, if we are lucky, someone else will for us. The new RDF
>>> Data Shapes WG works on exactly this. Unfortunately I'm not up
>>> to date with their work but Holger (CC'ed) is quite active in
>>> that group and may have a couple of minutes to give us a status
>>> update.
>> 
>> The Shapes group is still in its early stages - we are about to
>> finish (or freeze) the User Stories which are input to the
>> Requirements which we have started collecting. It is hard to say
>> how long that phase will take; I certainly hope this can be
>> covered in January and we have the first technical proposals
>> shortly after that. But who knows...
>> 
>> The topic of nested (or context-sensitive) property definitions
>> has come up in the group as well, and it will almost certainly be
>> covered by the
> 
> Good to hear that.
> 
>> resulting standard. For example, the Resource Shapes 2.0
>> language, which is one of the inputs to the WG, has a system
>> property :valueShape [1] that is linking a :Property with
>> additional constraints for its values. This is similar to
>> owl:allValuesFrom in that it allows you to use nested (blank)
>> nodes that go various hops deep from the starting point.
> 
> Quite straightforward :-)

The Resource Shape language is quite powerful, my impression is it
would solve most issues I have if we find a way to mix oslc (Resource
Shape 2) with hydra and schema.org. I'd like to start using it in
hydra-java right away, if that were possible :)

I have one problem with valueShape, according to [1] its
representation must be a reference, i.e. it does not seem possible to
inline it, and this is what I would like to do at the moment.
@Holger, your comment seems to imply that valueShape can hold nested
blank nodes. I couldn't find such an example, do you have one?

For demonstration I attempted to inline the valueShape for a
http://schema.org/Rating below.

Is the usage of oslc:ResourceShape together with hydra:Class below
legitimate?



{
    "@context":
    {
        "@vocab": "http://schema.org/",
        "hydra": "http://www.w3.org/ns/hydra/core#"
        "oslc": "http://open-services.net/ns/core#"
    },
    "@type": "Event",
    "@id": "http://example.com/hypermedia-api/events/2",
    "performer": "Cornelia Bielefeldt",
    "location": "Heilbronn",
    "eventStatus": "EventScheduled",
    "workPerformed":
    {
        "@type": "CreativeWork",
        "name": "Mein letzter Film",
        "review":
        {
            "@id":
"http://localhost:8180/webapp/hypermedia-api/reviews/events/2",
            "hydra:operation": [
            {
                "@type": "ReviewAction",
                "hydra:method": "POST",
                "hydra:expects":
                {
                    "@type": ["hydra:Class", "oslc:ResourceShape"],
                    "hydra:subClassOf": "Review",
                    "oslc:describes": "Review",
                    "hydra:supportedProperty": [
                    {
                        "@type": "hydra:SupportedProperty",
                        "hydra:property": "reviewBody",
                        "hydra:required": true
                    },
                    {
                        "@type": "hydra:SupportedProperty",
                        "hydra:property": "reviewRating",
                        "hydra:required": false
                    }],
                    "oslc:property": [
                    {
                        "@type": "oslc:Property",
                        "oslc:propertyDefinition": "reviewBody",
                        "oslc:occurs": "oslc:Exactly-one",
                        "oslc:valueType": "xsd:string"
                    },
                    {
                        "@type": "oslc:Property",
                        "oslc:propertyDefinition": "reviewRating",
                        "oslc:occurs": "oslc:Zero-or-one",
                        "oslc:valueShape": {
                           "@type": "oslc:ResourceShape",
                           "oslc:describes": "Rating",
                           "oslc:property": [
                           {
                               "@type": "oslc:Property",
                               "oslc:propertyDefinition": "ratingValue",
                               "oslc:occurs": "oslc:Exactly-one",
                               "oslc:valueType": "xsd:integer",
                               "xsd:minInclusive": 1,
                               "xsd:maxInclusive": 5
                           }
                           ]
                        }
                    }]
                }
            }]
        }
    }
}

1. Is it possible that this kind of inlining would be correct from the
perspective of Resource Shape 2? If not, is there a compelling reason
why a valueShape must be represented as a reference?

2. Some hydra properties seem to be very close to oslc which forced me
to use both, namely:

- - oslc:describes <=> hydra:subClassOf to say which type of subject is
expected
- - oslc:property <=> hydra:supportedProperty to hold multiple
oslc:Property (or hydra:SupportedProperty) objects
- - oslc:propertyDefinition <=> hydra:property to identify an expected
predicate

Biggest issue with that: If I would generate resources as shown above
with hydra-java, clients would get hydra:supportedProperty alongside
oslc:property.
- From the perspective of hydra - would that be desirable? How could
both be unified to avoid the duplications above? Right now I need to
use both to be understandable for "pure" hydra clients.

Best regards,
Dietrich

[1] http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#Property
[2] http://open-services.net/bin/view/Main/CmSpecificationV2Shapes


- -- 
Dietrich Schulten
Escalon System-Entwicklung
Bubenhalde 10
74199 Untergruppenbach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iEYEARECAAYFAlSgWCQACgkQuKLNitGfiZMFlQCfdniGv37uFDuA7k/0QRLT2XYj
UHQAoNsnMnh9yDHWw7sihepoi27A/tDD
=hccj
-----END PGP SIGNATURE-----

Received on Sunday, 28 December 2014 19:21:39 UTC