Re: Documenting implicit rdfs:domains of Hydra properties

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