Re: variable representations edited for spec

Hi Markus,

> I really like this summary (and fully agree with it). Maybe we should put it
> somewhere.. at least in the Wiki for the time being till we find a better place.

I've put it here for now: https://www.w3.org/community/hydra/wiki/Guiding_Principles
Linked from the start page. Feel free to change the title if too ambitious.

> Well, nothing prevents you from introducing another representation without
> that "extension point".

True; but I just can't declare it as such then.

> What I meant was that knowing that
> 
>  - BasicRepresentation is a VariableRepresentation
>  - ExplicitRepresentation is a VariableRepresentation
>  - *all* values of variableRepresentation are VariableRepresenations
> 
> doesn't change much in practice. How would you leverage that knowledge?

Suppose we have a GUI to build Hydra templates.
The knowledge that MyXyz is a VariableRepresentation
would allow the GUI to offer it as possible value for variableRepresentation.

> Maybe... but much more interesting would be
> to know how to use those (newly found) representation formats. We can't
> describe that at the moment. Thus I see limited value in introducing such a
> superclass and a range.

How about "I don't understand representation X, so I'm trying Y instead”.
Knowing that it's a representation helps.
It can be inferred from the fact that it's used as object of variableRepresentation;
but what exactly can we infer if there is no name for it? :-)

>> This case is likely too specific to put into the Core Vocabulary,
>> but by defining a hydra:VariableRepresentation,
>> I can explicitly tell a machine that this thing is a variable
> representation
>> and it is thus able to interpret how it can be used
>> (cfr. my remark about explicitness above).
> 
> Are you really able "to interpret *how* it can be used"?

*how* as in: can be used when a representation is expected,
such as in the GUI example above.

> You have to be aware though that more than
> likely no Hydra client will be able to make use of it since it hasn't been
> programmed to serialize values according to that representation format. The
> best it can thus do is to fail with a clear error message what went wrong.

Exactly—and that's not a bad thing

I don't perceive it as added complexity;
rather, it's defining a name for things that otherwise exist explicitly.
If you're not interested in extending Hydra, you don't need to know.

>> However, let's extend the interface with a structured free-text field:
>>    ?subject / ?predicate / ?object / ?freeText
>> where the ?freeText field allows control characters (*, ?, .).
>> Then the first 3 are hydra:ExplicitRepresentation,
>> and the 4th is ex:FreeTextWithControlChars.
> 
> Hmm... I'm not sure you need a separate representation format for that. My
> gut feeling is that defining a datatype that defines the query syntax would
> be the better choice in such a case. You can then serialize it either
> including the datatype (ExplicitRepresentation) or without
> (BasicRepresentation).

Nah, you run into modeling trouble then: the datatype won't match the property.

Suppose I can query foaf:Persons by lastname on wildcards.
I can't just simply say
   "?x foaf:familyName "?anthal*"^^<ex:wildcardExpression>
as foaf:familyName expects a proper string.
What I should say instead is:
   "?x foaf:familyName ?n"
where ?x matches the given wildcard expression.

> Apart from that, I do see some value in allowing different serializations
> within a single IRI template... I'm just *a bit* worried about the
> complexity and variability we introduce by that. Sure it might be able to
> save a couple of characters in the resulting IRI, but that's about it.

Mmm, I wasn't thinking about the savings, but about functionality.

> It neither simplifies serialization nor deserialization. In any case, I removed
> variableRepresentation's domain to not prevent this in the future.

+1

>> It's not about this use case per se (even though I will implement it),
>> but also to show that such use cases are actually quite common.
> 
> Another way to implement that would be to provide two IRI templates: one
> with subject, predicate and object variables and the other one with just the
> freetext variable.. but of course you can't combine them in that case.

Yes, and yes :-)
I don't want to complexify things, but we should be open to the extent possible.

>> The domain of this property would then be the union of mapping and template.
> 
> Which tells you what? :-P

That it's either one or the other :-)
You can make useful deductions from that.

> On the other hand, whether I have
> 
>   hydra:variableRepresentation rdfs:domain hydra:IriTemplate
> 
>   _:x hydra:variableRepresentation hydra:BasicRepresentation
>   ...
> 
> or
> 
>   _:x rdf:type hydra:IriTemplate
>   _:x hydra:variableRepresentation hydra:BasicRepresentation
>   ...
> 
> tells me (and a machine) exactly the same. The only difference is that the
> author needs to be more explicit. The clear advantage is that it gives us
> the flexibility to reuse hydra:variableRepresentation on things other than
> IRI templates in the future.

To me, this is the kind of flexibility that only humans deal well with.
Rigidity is why we have ontologies in the first place;
if machines understood more nuance, they wouldn't need them.

> Right. The question here is how we provide those instructions to machines.
> Do we want authors to be explicit or do we want to depend on reasoning by
> making the vocabulary more explicit and rigid? I lean towards the former
> because I expect that a lot of the things we define now could be cleanly
> reused for other things in the future.

I'd say both at the same time;
be rigid, so machines *could* do it even with few info.
But encourage humans to be explicit as well.

For instance, in our current Triple Pattern Fragments server, we say:
   <c> a hydra:Collection, hydra:PagedCollection.
even though the former can be inferred from the latter.
But if we are explicit, it also works with less advanced machines.

>> It costs us not significantly more to get the modeling right,
>> but it enables much more intelligent clients.
> 
> IMHO this has nothing to do with right or wrong modeling. The end result is
> exactly the same.

Only if people are explicit.

>> I separated those examples on purpose,
>> because the first example you give is already a special one: hydra:freeTextQuery.
>> This could lead people to think that hydra:property always expects a hydra:* value,
>> and they would have trouble connecting Hydra to their application domain.
> 
> Hmm.. I don't think that will happen.. and if it does, it's quite trivial to
> address it.

Think about it, freeTextQuery is really a very non-trivial example.
But I won't fight for it.

> Yep. I'm going to merge this now. Thanks again for taking the lead on this.

You're welcome, thanks for the support!

Best,

Ruben

Received on Tuesday, 30 December 2014 15:52:44 UTC