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

Changing the subject of this thread (was Re: terminology/necessity of
hydra:required) to reflect what is being discussed.

Sam, I cc'ed you because you were the one that proposed to allow both a
"SupportedProperty" and a "Property" as the value of "supportedProperties".
I would love to hear more about your thoughts on that.


On Monday, February 10, 2014 5:20 PM, Ruben Verborgh wrote:
> On Monday, February 10, 2014 4:25 PM, Thomas Hoppe wrote:
> > On 02/10/2014 11:30 AM, Ruben Verborgh wrote:
> > >>> Because then, the range of hydra:supportedProperty
> > >>> would be the union of rdf:Property and hydra:SupportedProperty.
> > >>> and hydra:SupportedProperty would still not be property nor
> > >>> rdf:Property.
> > >> Initially, I wasn't a big fan of that either but Sam convinced me
> > >> that in a
> > >> lot of cases it helps to drastically simplify the required markup.
> > >
> > > It does simplify.
> > > .but is simplification the most important goal here?
> > > It gets the model really messy and inexact.
> > > Is the trade-off worth it?

Could you please explain in a bit more detail why it becomes "messy and
inexact"? It don't see how you loose any precision. You just lose the
ability to *infer* some things.


> > > This should be discussed in more detail.

Yes we should. It would also be great if Sam (cc'ed) could join this
discussion as he's spent a lot of thoughts on this.


> > > I can think of a dozen things that could simplify;
> > > but not without loosing semantics.
> > > It's the wrong quality attribute here.

We have to find the right trade-off... almost always, that's the most
difficult thing.



> > >> If you don't need to make any further statements
> > >> about your supportedProperties, you just enumerate
> > >> them directly:
> > >>
> > >>    foaf:Person hydra:supportedProperty
> > >>        foaf:givenName ,
> > >>        foaf:familyName .
> > >>
> > >> If you need to describe them, you add a SupportedProperty construct
> > >> in between
> > >>
> > >>    foaf:Person hydra:supportedProperty
> > >>        foaf:givenName,
> > >>        [ hydra:property foaf:familyName ;
> > >>          hydra:required true ] .
> > >
> > > Here's a concrete problem:
> > >
> > >   foaf:Person hydra:supportedProperty
> > >        foaf:givenName ,
> > >        <http:/example.org/xyz>.
> > >
> > > Now what should I do?

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.


> > > Should I look up <http:/example.org/xyz>
> > > and see whether it is an rdf:Property or a hydra:SupportedProperty?

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.


> > > Or should I assume it is an rdf:Property? Or a
> > > hydra:SupportedProperty?

No, you can't assume anything here. You either have to know it already or
have to find it out. Please note that the server can drastically simplify
your life by including that information for you.


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


> > > That assumption is incorrect and leads to unclear modeling.

Fully agreed.


> > > This is messy. I don't like it at all.

You trade the ability to infer some knowledge for conciser, easier to read
descriptions. I wouldn't classify that as messy but maybe I missed
something!? Let me ask another question. Do you find foaf:primaryTopic
messy? It's range is owl:Thing as well.


> > Why not resolve the information what it is from the foaf vocab [1].
> >  From that I can learn that it is an rdf:Property _and_ that it is a
> > http://www.w3.org/2002/07/owl#DatatypeProperty
> > which clearly indicates that I can't dereference the value?
> > 
> > If the client is intended to do so, you could (at least in the case of
> > a JSON-LD format) define the property as "@type": "@id";
> > 
> > Otherwise I would expect clients to understand whether a property must
> > be be further dereferenced or not from the bare semantics of it.
> > 
> Exactly my point; there's no other option except doing that.
> That's possible, I know. That's not too hard, I know-at at least in
> most cases.
> But this assumes that:
> a) the client can dereference the thing (is URL, server up, reachable,
> still exists, etc.)
> b) it can parse the representation (HTML? RDF/XML? Turtle? Or JSON-LD?)
> c) it will say rdf:Property or a derived class (such as
> owl:DataProperty)
> d) if it is "derived class", that I can dereference it until I find it
> is or isn't an rdf:Property (restart from a)

All correct, but what can you do in the end with the property or
supportedProperty if you don't know what it is really about? Can you use it
without understanding it? I doubt that... I should probably say that
initially I had exactly the same reservations as you have but I came to the
conclusion that in practice all of this doesn't really matter as you have to
do those things anyway.


> Much easier to model it correctly from the start.
> 
> > and_ that it is a http://www.w3.org/2002/07/owl#DatatypeProperty
> > which clearly indicates that I can't dereference the value?
> 
> That doesn't really matter here, right?

I collapsed a number of mails into this one here and you already solved this
misunderstanding in the other thread.


> Only thing that matters is whether it is an rdf:Property or a
> hydra:SupportedProperty (and hopefully, both classes are distinct).

Right, to better reflect this. I've changed the subject of this thread and
created ISSUE-37:

  https://github.com/HydraCG/Specifications/issues/37


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 10 February 2014 22:04:44 UTC