RE: Nested supportedProperty

On 16 Dez 2014 at 23:38, Holger Knublauch wrote:
> On 12/17/2014 8:16, Markus Lanthaler wrote:
>> 
>>> 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:name is bound to Thing, and then inherited down into all other

Right.. I realized that that is a particularly bad example right after
hitting the send button


> classes. Similarly, any other global property can be defined.
> Alternatively, if only some classes can have a property, then there are
> these alternatives:
> 
> 1) Define a global range/domain, e.g.
> 
>      schema:email schema:domainIncludes schema:Organization
>      schema:email schema:domainIncludes schema:Person

What exactly do you mean by global range/domain?


> 2) Define an abstract superclass and use inheritance
> 
>      schema:email rdfs:domain schema:ThingWithEmail
>      schema:Person rdfs:subClassOf schema:ThingWithEmail
>      schema:Organization rdfs:subClassOf schema:ThingWithEmail

Yeah.. that's the "traditional" way of doing it.. it normally introduces
quite a lot of "artificial" classes which are only there due to those
modeling constraints and I'm not entirely sure what you gain by that

> Option 2 is what someone would do in an OO language, and it's easier to
> convert back and forth with OO systems. The syntax that I would propose
> for a future (shapes) language would be

Well, yeah if you either get rid of multiple inheritance or if you choose to
interpret/map this to interfaces instead of classes in most OO languages. 


> schema:ThingWithEmail
>      a rdfs:Class ;
>      :property [
>          :predicate schema:email ;
>          :valueType xsd:string ;
>          :label "email address" ;
>          :comment "..." ;
>          :pattern "some regex" ;
>      ] .
> schema:Person
>      a rdfs:Class ;
>      rdfs:subClassOf schema:ThingWithEmail .
> schema:Organization
>      a rdfs:Class ;
>      rdfs:subClassOf schema:ThingWithEmail .
> which keeps all properties locally scoped.

And what prevents you from doing that with global properties?


>>> 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.
> 
> Yeah, but just having "hints" is not really sufficient to build input
> forms. Why only have hints if you can have the real thing.

Right.. it was not intended to be used to render input forms. Of course you
could provide a mechanism for the user to choose one of the potential ranges
and build the form based on that decision though. I think defining a
vocabulary itself and describing how it is to be used in a certain context
are two quite different things. In Hydra we try to capture the later with
what we call a hydra:ApiDocumentation. These are not globally valid
constraints but just apply in the context of a specific Web API. You can do
the same by defining different shapes AFAICT.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 17 December 2014 23:22:59 UTC