RE: representing hypermedia controls in RDF

Hi Ruben,

I'm gonna to reply to two of your mails here

On Monday, November 25, 2013 2:20 PM, Ruben Verborgh wrote:
> > 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]

OK, so we are on the same page. Currently however, hydra:Link is *not*
defined to be property itself. It is a class. I didn't want to introduce the
notion of generic, untyped hyperlinks as I didn't see how they could be used
for anything but simple crawling. This is closely related to ISSUE-15 [1]
(Define a property to be used for untyped links?).

And here's your second mail:

On Monday, November 25, 2013 6:31 PM, Ruben Verborgh wrote:
> > Note: by saying
> >    hydra:Link rdfs:range hydra:Resource .
> > you make hydra:Link a rdf:Property
> 
> Actually, that makes me wonder whether hydra:Link should not be a
> subproperty of rdf:Property (instead of an instance),

hydra:Link is not an instance of rdf:Property. It's a subclass thereof.
Maybe this makes it clearer: I don't want it to be used as in

  </a> hydra:Link </b> .

I want it to be able to distinguish between properties:

  :x rdf:type hydra:Link .
  :y rdf:type rdf:Property .

  </a> :x </b> .
  </a> :y </c> .

:x is a hyperlink here, :y is not. What I meant when I spoke about
entailments in one of my earlier mails is that 

  </a> :x </b> .

should entail

  </b> rdf:type hydra:Resource .

You are completely right by saying that we could achieve that by making
hydra:*l*ink a property itself and create sub-properties thereof. Unless we
want to go down that route however (again, ISSUE-15) I don't like this
solution as it eliminates the symmetry btween rdf:Property and hydra:*L*ink.


> with the restriction that instances of hydra:Link should have
> hydra:Resource as rdfs:range.
> So hydra:Link should be a class, not an instance.

It is a class:

  hydra:Link rdfs:subClassOf hydra:Resource, rdf:Property .


> Then this:
> >    :myprop rdf:type hydra:Link.
> 
> would be the correct way to enable all the inferences I showed out-of-
> the-box.
>
> I started thinking that you really mean hydra:Link as a subproperty and
> hence should define it as such.
> This thus means that "hydra:Link rdfs:range hydra:Resource" may not
> occur.

I'm lost here. :myprop rdf:type hydra:Link is exactly what we do at the
moment but I can't see how

  </a> :myprop </b> .

turns </b> into a hydra:Resource in that case using just RDFS entailment.
Could you help me out here?


And back to the first mail...

> 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.

Link is not a property - at least not at the moment.


> 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.

Yeah, that's what I meant above but for the reasons state above hydra:Link
is not a property atm.


[...]
> > 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;

... at the cost of making it more difficult to work with Hydra.


> the latter rely on the Hydra convention, knowing that no other parser
> can interpret it.

Sure, if you just look at the string that's true but if you also use the
hydra:template variable it is trivial to interpret it. I'm still not
convinced. I see the preciseness it allows but find it overkill at the
moment. Just imagine schema.org would require proper datatyping etc. I think
that wouldn't be very beneficial in terms of adoption.


> > 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.

Would it be OK for you if we define this in a separate spec for those who
care?


> Start typing them now, then the convention is opt-in. Now, it is
> mandatory.

It's also about reducing the choices a developer has to make. Every option
you introduce decreases interoperability and makes implementations more
complex.


> > 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?

Please let's try to keep the discussions 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.

Would you volunteer to convert the examples to Turtle?

I'm still very skeptical about this. Turtle has been around for a decade now
and I have yet to see a Web API (outside the small Semantic Web community)
using it. JSON-LD on the other hand is still quite young and already widely
used. 

[...]
> >> 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.

Right, that's what I'm trying to say. Not many web developers think in terms
of triples. People with a strong Semantic Web background as you do but that
community is tiny compared to the group of web developers fluent in JSON.


> 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.

The question is, has it to?


> 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).

Yeah, and I hope this is not turning into a syntax war :-) The reason why
everything is in JSON(-LD) at the moment is simple: most developers are
familiar with it, it's used in almost every Web API I'm aware of, most
people IMO don't care and don't understand inferences etc., introducing an
additional syntax confuses many people as they don't understand why there
are two, which to use when (Microdata vs. RDFa, anyone?), etc. etc. 


> 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.

I agree that everyone has personal preferences, I certainly do... and as you
probably noticed I'm switching back and forth between JSON-LD and Turtle
quite a lot. Nevertheless I don't find that argument compelling enough (yet)
and still very concerned about the potential confusion it may introduces.


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

I've created ISSUE-18 [2] to keep track of this. Let's see if other people
(preferably non-SemWeb experts) complain about it.


> > 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

By simple I meant to keep my job simple :-) There are no examples to keep in
sync, no difference between syntaxes to be explained, no additional demo to
create, etc.


Cheers,
Markus


[1] https://github.com/HydraCG/Specifications/issues/15
[2] https://github.com/HydraCG/Specifications/issues/18


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 26 November 2013 13:42:10 UTC