RE: Nested supportedProperty

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


> So although I cannot speak on behalf of the WG, I believe this topic
> will be covered by the new shapes language, and we will hopefully come
> up with something that can be plugged directly into Hydra and similar
> frameworks.

Yeah, hopefully


> On the more general topic of properties being global or scoped to
> classes, I believe the schema.org people followed the concepts explored
> by RDF Schema (with variations of global range and domain definitions),
> yet I do not believe there are strong reasons for defining property
> semantics this way. I believe it would be more helpful to align the

This is probably not the right place to discuss this but IMO there are quite
a few reasons to define properties that way. Just think of schema.org/name.
If it would be bound to a specific class, a client would need to understand
dozens of variations of basically the same concept (or infer something from
the URL structure).


> schema.org model with traditional object-oriented modeling, where a
> property would be attached to a class. This resolves some of the
> problems with overlapping domains/ranges. For example what would happen
> if a property has two rangeIncludes and two domainIncludes - which
> combinations are really valid? If you scope a property declaration to
> the context of a class, this issue is solved much clearer.

rangeIncludes and domainIncludes are not about validity.. they are hints as
to what a client should likely expect to find in the subject/object... but
I'm sure you know that.


Cheers,
Markus


> [1] http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#valueShape


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 16 December 2014 22:17:01 UTC