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

On Tuesday, February 11, 2014 1:12 PM, Ruben Verborgh wrote:
> 
> Slightly changing order to have the main arguments on top.

OK


> > Let me ask another question. Do you find foaf:primaryTopic
> > messy? It's range is owl:Thing as well.
> 
> "The primaryTopic property relates a document to the main thing that
> the document is about."
> Since a topic can literally be anything, owl:Thing is the best match.
>
> It's not messy, because it is correct. There are no other ways to model
> this.

Well, you could introduce a class that represents topics but that's beside
the point.


> In contrast, we do have other options for properties in Hydra.
> 
> > Could you please explain in a bit more detail why it becomes "messyand
> > inexact"? It don't see how you loose any precision. You just lose the
> > ability to *infer* some things.
> 
> Try to draw a diagram. You will see what I mean with messy ;-)

Here we go:
                    ---------
 -------           | SupProp |
| Class |          |---------|
|-------|   ,------|  prop. -|----.
|supProp|--<        ---------      \    --------------
 -------    \                       >--| rdf:Property |
             `---------------------´    --------------

I personally don't find this overly messy but I see what you mean.


> Let me try to illustrate in words:
> 
> There is a relationship called hydra:supportedProperty
> from hydra:Class to… well, it splits into hydra:SupportedProperty and
> rdf:Property.
> Or perhaps there is a separate class to represent
> the union of hydra:SupportedProperty and rdf:Property.
> Then there is a relationship called hydra:property
> from hydra:SupportedProperty to rdf:Property.
> 
> SupportedProperties are not Properties but they have a property
> property.
> Properties can be a supportedProperty but they are not
> SupportedProperties
> and hence have no property property (but can be a property of a
> SupportedProperty).
> 
> I'm really not trolling here, but trying to illustrated the messiness.

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.


> > We have to find the right trade-off... almost always, that's the most
> > difficult thing.
> 
> +1
> 
> > That depends what you wanna do with this information. I assume you
> > want to use it to create an HTTP request. In that case, you need to
> > have some understanding of what foaf:givenName and http:/example.org/xyz
> > mean.
> 
> > If you don't know it yet, yes, that's what you should try. Maybe it
> > leads you to a description thereof that you can understand. If not,
> > you can't do anything with it.
> 
> But it would be easier if Hydra just told me.

Without any doubt, yeah. So you prefer the current version, right?


> >>>> You seem to silently assume that people will either give
> >>>> a URI that is an rdf:Property or a blank node that is a
> >>>> SupportedProperty.
> >
> > No, I'm not.
> 
> Apologies, I misinterpreted!
> 
> > You trade the ability to infer some knowledge for conciser, easier to
> > read descriptions.
> 
> Hydra's primary purpose is machine-readability (correct me if I'm
> wrong);
> machines can do much more by having the modeling more strict.
> Shouldn't be less clear.
> 
> This (and other discussions) bring me to another question:
> should we have an ordered list of quality attributes / goals?
> Like: if a decision has to be made, X and Y weigh more than A and B?
> If we agree on such a list, decisions could be taken more confidently.

That would be helpful, yes. I especially like the "priority of
constituencies" as defined by the HTML WG:

  "In case of conflict, consider users over authors over implementors
   over specifiers over theoretical purity. In other words costs or
   difficulties to the user should be given more weight than costs to
   authors; which in turn should be given more weight than costs to
   implementors; which should be given more weight than costs to
   authors of the spec itself, which should be given more weight than
   those proposing changes for theoretical reasons alone. Of course,
   it is preferred to make things better for multiple constituencies
   at once."

[http://www.w3.org/TR/html-design-principles/#priority-of-constituencies]



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 11 February 2014 19:37:34 UTC