- From: Jindřich Mynarz <mynarzjindrich@gmail.com>
- Date: Mon, 16 Jun 2014 00:05:02 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org
Hi Markus, On Sun, Jun 15, 2014 at 10:07 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote: > We are more than happy to answer all your questions. Don't be afraid to ask. Thank you for your response. > I might misunderstand you here since you state you have semantic web background but rdfs:domain doesn't tell you what classes a property is "compatible with" and it is also not just a hint. As I'm sure you know, if you have a property "myproperty" with a domain of "MyClass" and then use that property to state that > > /my-resource myproperty "some value" > > It means that /my-resource is of class MyClass. You are stating that indirectly by asserting the property's domain. I meant that rdfs:domain is a hint of class membership, because the use of a resource with a property of specified rdfs:domain implicitly casts the resource as a member of the class specified by rdfs:domain. In this way, vocabulary users are guided to reach for a specific property only if they're comfortable with the class membership it implies for the resource it's used with. > > * hydra:apiDocumentation - I assume that any hydra:Resource is > > compatible with this property. > > * hydra:freetextQuery - hydra:Resource? > > * hydra:search - hydra:Resource? > > It is rdf:Resource, basically everything. Since everything is implicitly of type rdf:Resource, it is unnecessary to state this explicitly. Hydra describes hydra:Resource as a rdfs:subClassOf rdfs:Resource, not as its owl:equivalentClass, which is why I thought it might be more specific and therefore more meaningful to use in rdfs:domain assertions. However, if its rdfs:domain is meant to be rdfs:Resource, then you're right to say that it's unnecessary to state it in the RDF description of the vocabulary, but it still might be helpful to document the absence of rdfs:domain isn't an omission. > > * hydra:description - hydra:description schema:domainIncludes > > hydra:ApiDocumentation, hydra:StatusCodeDescription . > > * hydra:property - schema:domainIncludes hydra:SupportedProperty, > > hydra:IriTemplateMapping . > > * hydra:required - schema:domainIncludes hydra:SupportedProperty, > > hydra:IriTemplateMapping . > > * hydra:statusCodes - schema:domainIncludes hydra:ApiDocumentation, > > hydra:Operation . > > * hydra:supportedOperation - schema:domainIncludes hydra:Class, > > hydra:Link . > > * hydra:title - schema:domainIncludes hydra:ApiDocumentation, > > hydra:StatusCodeDescription . > > Again, the domain would be rdf:Resource. But you are right, using schema:domainIncludes would make sense in these cases. We don't use domainIncludes at all till now because it is of very limited value for machines. But obviously it helps people such as yourself and also to generate better documentation. Sure, schema:domainIncludes as it stands is more of a documentation property helpful to human readers of vocabulary specifications. If you're looking for a description readable for machines, then simple OWL may be put to use: hydra:supportedOperation rdfs:domain [ owl:unionOf ( hydra:Class hydra:Link ) ] . However, I guess this is useful only for illustration purposes, as I recall that you'd like Hydra to avoid depending on OWL (http://lists.w3.org/Archives/Public/public-hydra/2014Apr/0050.html), which makes very much sense. > > Is this a more or less correct understanding? I think having these > > relationships explicitly documented in the vocabulary (and not only in > > the vocabulary's diagram) would make its intended uses clearer. > > Yes. Unless someone objects, I'll add those statements in the next couple of days. I've created ISSUE-48 to track it: > > https://github.com/HydraCG/Specifications/issues/48 I hope this can clarify the relationships that are implicitly taken into account in Hydra's diagram and help the vocabulary users to employ the described properties as intended. I don't think the additional assertions will confuse any of the vocabulary's users, but I'd like to hear opinions of others who reckon it might be the case. Best, Jindřich -- Jindřich Mynarz http://mynarz.net/#jindrich
Received on Sunday, 15 June 2014 22:05:49 UTC