Re: representing hypermedia controls in RDF

Hi Markus,

> hydra:Link is not an instance of rdf:Property. It's a subclass thereof.
> Maybe this makes it clearer: I don't want it to be used as in

Okay, I was confused by

> hydra:Link rdfs:range hydra:Resource .

but this statement is not true in the current spec. Good.

> I don't like this solution as it eliminates the symmetry btween rdf:Property and hydra:*L*ink.

Good.

> I can't see how
> 
>  </a> :myprop </b> .
> 
> turns </b> into a hydra:Resource in that case using just RDFS entailment.
> Could you help me out here?

RDFS entailment alone won't do indeed.
We need to describe hydra:Link in more depth with OWL:
    hydra:Link rdfs:subClassOf [ owl:onProperty rdfs:range; owl:hasValue hydra:Resource ].

Given the above and [1][2][3], the following:
    :myProp a hydra:Link.
    :a :myProp :b.
results in
    :myProp rdfs:range hydra:Resource.
    :b a hydra:Resource.
as tested with the EYE and cwm reasoners, which is what we want.
Similar for rdfs:domain of course.

Again a confirmation of the fact that hydra:Link should be a subclass of rdf:Property.

>> People who know how to type strings, use hydra:rfc6570Template for exactness.
>> People who don't know or care use string.
>> The former make sure the templates can be interpreted correctly by others;
> 
> … at the cost of making it more difficult to work with Hydra.

No, because the convention remains. Let me show you.
In both cases, you need to obtain the value from a literal.
It's
    "mytemplate"^^xsd:string
versus
    "mytemplate"^^hydra:rfc6570Template
The process of obtaining the value "mytemplate" out of that is the same.

Applications that don't care about types needn't.
Applications that choose to care, can.

> Just imagine schema.org would require proper datatyping etc. I think
> that wouldn't be very beneficial in terms of adoption.

Again, it's not "require". The convention remains; preciseness is opt-in.

> Would it be OK for you if we define this in a separate spec for those who care?

Well, of course you needn't set up a separate spec for me :-)
That said, if there are more detailed bits like this… that would be a good place!

> It's also about reducing the choices a developer has to make. Every option
> you introduce decreases interoperability and makes implementations more complex.

Fully agree to that, and that makes an advanced spec appealing.
(Sort of like the RDF primer versus the full story.)

Cheers,

Ruben

[1] http://eulersharp.sourceforge.net/2003/03swap/rdfs-subClassOf.n3
[2] http://eulersharp.sourceforge.net/2003/03swap/owl-hasValue.n3
[3] http://eulersharp.sourceforge.net/2003/03swap/rdfs-range.n3

Received on Tuesday, 26 November 2013 14:54:24 UTC