Re: representing hypermedia controls in RDF

Hi Markus,

> I doubt that
> someone would come to the conclusion that if some door handles don't work,
> the whole idea of door handles is broken. Right? :-)

Right :-)
So a link is a property with the expectation you can dereference it.

>> Entailments for RDFS and OWL are already defined (e.g. [1]).
> You forgot the link

Should be [1] http://eulersharp.sourceforge.net/2003/03swap/rdfs-range.html

> are you saying that
> 
>  hydra:Link rdfs:range hydra:Resource .
> 
>  :myprop rdf:type hydra:Link .
>  </something> :myprop </something-else> .
> 
> entails
> 
>  </something-else> rdf:type hydra:Resource .
> 
> ? I don't think so, but I would love to be proven wrong. That would just
> work if hydra:Link would be a property itself and you create sub-properties
> thereof.

Note: by saying
    hydra:Link rdfs:range hydra:Resource .
you make hydra:Link a property, since
    rdfs:range rdfs:domain rdf:Property.
and
    {?P rdfs:domain ?C. ?X ?P ?Y} => {?X a ?C}. [2] 

However, the problem is here:
    :myprop rdf:type hydra:Link.
The "rdf:type" predicate is not precise enough.
You actually want to say:
    :myprop rdfs:subPropertyOf hydra:Link.
as Link _is_ a property, and rdfs:subPropertyOf details the relationship in a better way.

If that is the case, then through [1], [3] and
    hydra:Link rdfs:domain hydra:Resource
    :myprop rdfs:subPropertyOf hydra:Link.
    </something> :myprop </something-else> .
follows indeed that
    </something-else> rdf:type hydra:Resource.

>> <x> hydra:template "old-template"^^hydra:rfc6570Template.
>> <x> hydra:template "new-template"^^rfc25000:template.
>> 
>> So the same resources can have multiple templates in different standards.
>> That's extensibility.
> 
> But at the same time you require everyone to type their strings accordingly.
> I already hear you saying "no, you can set rdfs:range and it will be done automatically".

No, you cannot. The purpose of adding it would precisely be because it cannot be inferred automatically,
as multiple variants would be allowed.

> And that's exactly same situation as we have now. We interpret plain strings as RFC6570 templates.

That's a convention, which could be acceptable.
Still, that does not mean that hydra:rfc6570Template cannot be useful.

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;
the latter rely on the Hydra convention, knowing that no other parser can interpret it.

> If there's really something better coming up in the future, it's early
> enough to start typing those strings. It's just as extensible. 


I like the convention, but I strongly suggest offering the exact solution as well.
Start typing them now, then the convention is opt-in. Now, it is mandatory.

> I would love to hear other opinions as well.
> I've created ISSUE-17 [2] to keep track of these discussions.

Thanks! Should I add comments like these over there, or on the mailing list?

> I doubt that very much. The target group of Hydra are average web developers
> not semantic web experts. Those will understand themselves that they can use
> this stuff with, e.g., Turtle as well. I don't want to confuse Web
> developers with multiple serialization formats or "triples".

The thing is, I consider myself an expert in both Semantic Web and JSON,
yet I have trouble understanding the representations (because I'm not a JSON-LD expert).
So imagine the trouble average Web developers have.

I don't want to turn this into an expert-only thing,
but if experts cannot understand it fluently, we got ourselves a problem.
Few people are fluent in JSON-LD, even though it is JSON and thus supposedly easy.

I fully support the JSON-LD idea, but Hydra is about building bridges.
But Hydra is not as simple as "just Turtle", there is a SemWeb theory behind the whole thing
and it matters, whether we like it or not. (I assume we like it.)

So please consider at least adding the option to switch to Turtle.
If you don't get traction from both sides, it won't work.

>> Not many JavaScript applications will read vocabs; those that do have
>> an RDF library anyway.
> 
> This almost sounds as you could work with Turtle without a RDF library.

No, I mean that the _vocabulary_, so doing operations with this file
(such as the inferences I discussed above) requires a SemWeb background.
And those people understand Turtle far better than JSON-LD.

> On the other hand, it's is very easily
> possible to achieve a lot without special libraries by using JSON.

Yes, but not vocabulary manipulations; they happen in the RDF model domain.

>> For instance, my understanding is quite slowed down by the syntax.
> 
> That's the first time I hear something like this. The JSON-LD really slows
> you down? How? What exactly would be clearer if Turtle would be used instead?

Interesting. I think it is very important that the question is asked to many people.
For me personally (and I'm not exaggerating), it is similar to my understanding of RDF/XML.
I don't read RDF/XML fluently. I have a good knowledge of XML and can make sense out of it,
but when I see Turtle, the triple graph forms in my head and I can see it and do mental operations.
When I see JSON-LD, I see JSON for the moment, which is a hierarchy.
E.g., the triple model doesn't come to live with JSON-LD.

Now, this is just because I'm not used to JSON-LD and will change the more I use it.
It's by far_not_ a syntax problem (JSON-LD has a good syntax).

The inferences we discussed above, I would not have been able to make them in JSON-LD.
This is a human thing of course; I know they are perfectly equivalent.
But if I don't "see" the triples, I can't do the math.
I think the average Web developers you talked about above "see" JSON; and that's just what I see.

If I'm the only one, please ignore me.
But I have the feeling there are others just like me.

> Sure, we could do that and add Turtle examples in the future. For the time
> being I would prefer to keep it simple and stick to JSON-LD. I'm sure you understand that.

I perfectly understand and don't worry about me.
But understand that "simple" is a matter of perspective
and few people are as fluent in JSON-LD as you are.
Even though I fully understand JSON, I have trouble reading the spec.
Please ask people's opinions—a spec that can't be read easily won't be.

Best,

Ruben

[1] http://eulersharp.sourceforge.net/2003/03swap/rdfs-range.html
[2] http://eulersharp.sourceforge.net/2003/03swap/rdfs-domain.html
[3] http://eulersharp.sourceforge.net/2003/03swap/rdfs-subPropertyOf.html

Received on Monday, 25 November 2013 13:20:48 UTC