Re: Nested supportedProperty

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

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

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

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.

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

Holger

Received on Tuesday, 16 December 2014 22:41:58 UTC