- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Fri, 9 Oct 2015 23:00:35 +0200
- To: Karol Szczepanski <karol.szczepanski@gmail.com>
- Cc: public-hydra@w3.org
Hi Karol, >> But that's not what your RDF above says. >> It says that the operation return _:someResource. > Well, not really. I used blank node. That doesn't make a difference. Blank nodes are just different identifiers [1], but that doesn't change the fact that the operations returns _:someResource (or whatever identifier it has). > my:restOperation hydra:expects [a hydra:Resource; imaginary:ofClass schema:Action . ] . > > It really says that the operation expects something that is a resource of type schema:Action. No, it says that it returns that specific blank node (and that blank node happens to be an action). > This is how RDF spec treats blanks - something that is unnamed. I agree—but named or not, the "my:restOperation hydra:expects X" statement says that "my:restOperation returns X". Whether or not X is identified by an IRI or a blank node doesn't make a difference in interpreting that statement. I understand your intention, but that's not what the actual RDF says. Whether or not that object of the stament happens to be identified with a blank node does not make its interpretation different from had it been an IRI. >> Even if you define "hydra:expects" very liberally, >> we'll still run into problems (as the "imaginary" shows). >> _:someResource is not a resource but a prototype for a resource. > I don't agree - prototype would look like the genuine one, but with some fakes here and there. You'd have to fake everything except literals, i.e., fake every property and resource object. >> Pages are certainly not details; we need to get this straight. > True, but specific links like first or last page are. I prefer to tell client on how to craft a link to a page (give him a fishing rod) rather than to tell him every single possibility hoping any of them will be of use to him (give him fish instead). Disagree here; "next page" is a far more common use case than jump. >>> Example: hydra:property has a range of rdf:Property and this class can have in it's range an owl:Restriction - this is the shortest path to problems. >> No. > O yes. Consider this: > my:restOperation hydra:expects [ > owl:onProperty bar:serves; > owl:allValuesFrom [ owl:intersectionOf (alcohols:Wine [owl:onProperty bar:hasColor; owl:hasValue bar:Red]) ] > ] > What kind of machinery on the client side would be required to find out that the operation expects an instance of a red wine service? a) None, if you just use "alcohols:RedWine" instead. b) The Hydra Core Vocabulary cannot prohibit this in any way, so it is meaningless to even try to do so. You cannot say that the subject of hydra:expects cannot be an owl:Restriction, because _any_ possible value of it is an owl:Restriction. To understand b), note that for any possible object for hydra:expects holds: my:restOperation hydra:expects [ owl:onProperty dc:title; owl:minCardinality 0 ]. I.e.: any object of hydra:expects can at least have 0 titles. That's universally true; nothing anybody can do about that. Prohibiting owl:Restriction means prohibiting anything. Best, Ruben [1] http://www.w3.org/TR/rdf11-concepts/#section-blank-nodes
Received on Friday, 9 October 2015 21:01:06 UTC