W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

RE: Documenting implicit rdfs:domains of Hydra properties

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Sun, 15 Jun 2014 22:07:48 +0200
To: <public-hydra@w3.org>
Message-ID: <032b01cf88d5$7b8fb1a0$72af14e0$@gmx.net>
Hi Jindřich

On Sunday, June 15, 2014 2:56 PM, Jindřich Mynarz wrote:
> in the last few days I was trying to grasp Hydra. I started with the
> Hydra's specification and continued with reading the public-hydra
> mailing list, which helped me to clarify a few bits of the Hydra's
> approach, but still left me with several questions open.

We are more than happy to answer all your questions. Don't be afraid to ask.


> One of the key aids that helped me to understand Hydra is its diagram
> (http://www.hydra-cg.com/spec/latest/core/vocabulary.png), which
> provides a good overview of how Hydra's vocabulary terms are related.
> However, what I find confusing is that some of the relations depicted
> in the diagram aren't present in Hydra's description in RDF
> (http://bit.ly/hydra-core-ttl). In particular, I'm missing rdfs:domain
> (or schema:domainIncludes) axioms, which would help me (and,
> presumably, other developers with semantic web background) to orient
> in the vocabulary. Having rdfs:domain explicitly set for properties
> would help to recognize which classes are the properties compatible
> with; even if this is to be treated with open world assumption as just
> a hint.

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've scanned through the RDF description of the Hydra Core Vocabulary
> and found the following properties, which could be enriched with
> rdfs:domain or schema:domainIncludes, which would likely be a better
> fit in this case. For each property I tried to guess, mostly using the
> Hydra's vocabulary diagram (http://www.hydra-
> cg.com/spec/latest/core/vocabulary.png), what are its compatible
> classes.
> 
> * 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: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.

 
> 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


Thanks,
Markus


--
Markus Lanthaler
@markuslanthaler
Received on Sunday, 15 June 2014 20:08:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC