Re: terminology/necessity of hydra:required

On 02/10/2014 05:19 PM, Ruben Verborgh wrote:
>>> 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.
>>> That assumption is incorrect and leads to unclear modeling.
>> Why not resolve the information what it is from the foaf vocab [1].
> 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)

Sure, not every client can do this.

>
> Much easier to model it correctly from the start.

Well I wouldn't say that the above process is incorrect it's
just out of reality in many scenarios.
But what do you consider "right"? Allow to define whether
an IRI or a literal is expected?

>
>> 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?
> Only thing that matters is whether it is an rdf:Property or a hydra:SupportedProperty
> (and hopefully, both classes are distinct).

Hmm, I thought with owl:DatatypeProperty you have always literal while
with rdf:Property this isn't the case.

>
>> Otherwise I would expect clients to understand whether a property must be
>> be further dereferenced or not from the bare semantics of it.
> What are "bare semantics of it"?

If the client knows what a foaf:givenName is, it might infer that
the value is a literal and not an IRI. But of course there is nothing
that stops you from linking to 'http://wiki.name.com/en/Maggie' for example.

>
> Best,
>
> Ruben

Received on Monday, 10 February 2014 20:25:14 UTC