Re: Define/change the range of "supportedProperties" (ISSUE-37)

On 02/11/2014 11:48 PM, Ruben Verborgh wrote:
>> So, according to you, lies the crux of the problem in the used terminology
>> or in the structure of the graph? I definitely agree that the terminology is
>> confusing if you look at it from this perspective.
> Both really, they are connected to each other.
> SupportedProperty is now a proxy around property
> to allow us to attach extra metadata like hydra:required.
>
> I'd suggest to make that proxy mandatory (= stricter modeling)
> and give it a name that doesn't involve "Property".

Just to prevent misunderstandings: you propose to make 
supportedProperties mandatory for classes?

I don't like that because I think we need to allow for other strategies 
than the explicit enumeration
of supported properties on classes. I discussed this on the past on the 
list when I naively asked why
it isn't possible to resolve properties from classes defined in vocabs.
Meanwhile I understood this isn't possible with a simple RDFS based 
vocab but it can be expressed
with OWL (reverse relationship between property and class).
This is just one case where you might not want to enumerate the 
supported properties
and I can think of other such as a vocabulary where the concept of a 
class with properties is
intrinsic (schema.org seems to be like this).


>
>> Without any doubt, yeah. So you prefer the current version, right?
> Yes, but I'd like to see more intuitive naming.

 From this POV above, I like the current naming.
Even if it would be mandatory, why do you want to get rid of the term 
'property'?

>
> But enough from me about this. What are others' opinions?
>
>> That would be helpful, yes. I especially like the "priority of
>> constituencies" as defined by the HTML WG.
> That would be awesome. Let's start a list like that!
> (Where? GitHub Wiki?)
>
> Ruben

Received on Friday, 14 February 2014 07:02:49 UTC