Subject: [core] draft-hartke-t2trg-coral and reef

From: Jim Schaad <[email-masked]>
Date: Sun, 14 Jul 2019 20:04:26 -0700

I have run across the following questions:

CoRAL:

1.  When applying a dictionary, is the expanded value always treated as a
string or is it a typed item.  The difference would be if you matched both
"0" and 0 when doing the conversion between the representations?  This also
has implications with respect to doing IRI comparisons for CIRI

2.  Are dictionaries applied to each element in a CIRI or just to the CIRI
as a whole?

3.  I think the answer to this is going to be it does not matter, but does a
CIRI need to be made absolute prior to doing the dictionary lookup?  The
reason why I say this is that it would be really unexpected to have a prefix
URI in a dictionary that would match a CIRI as a target where the target is
relative to the current node.

3.  What happens for a parser if the generator used a newer version of the
dictionary than it has?  Thus there is an element 22 and I cannot understand
it.

Reef:

1.  Is the Resource Metadata in section 3 missing "reef#ep" ?  Looking at
some of the examples - has the idea of an endpoint name and a domain just
vanished?

2.  What is the correct behavior for an attribute such as "obs" when it was
set using link format and then retrieved using CoRAL?  

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 16 Jul 2019 19:43:52 +0200

Hi Jim!

> "0" and 0 when doing the conversion between the representations?

The expanded value is a typed item.

> 2.  Are dictionaries applied to each element in a CIRI or just to the CIRI

draft-hartke-t2trg-ciri-03 doesn't make use of dictionaries at all; a
CIRI itself cannot refer to a dictionary entry.

draft-hartke-t2trg-coral-09 allows you to put a dictionary key in
certain places where a whole CIRI is expected.

That's how it's currently specified. The current idea is to build up a
small repository of real-world examples and then revisit the whole
topic of compressing duplications in a CoRAL document.

> relative to the current node.

draft-hartke-t2trg-coral-09 only really tells you what it means when a
recipient sees a dictionary key in a document. It's up to the
generator to decide how it puts dictionary keys into it.

I think it might be useful to have some relative references in the
dictionary. For example, I could imagine you might want to link to
</.well-known/core> relative to the current resource.

> dictionary than it has?  Thus there is an element 22 and I cannot understand

It's indeed undesirable if extending a dictionary with new entries
breaks consumers using an older version.

This is one of the blocking issues that needs to be solved. I don't
have a good idea yet.

> some of the examples - has the idea of an endpoint name and a domain just

In general, the draft doesn't try yet to exhaustively replicate all
the features of draft-ietf-core-resource-directory-23 (due to lack of
time mostly).

The idea of endpoint name and domain is something that somehow always
immediately escapes my mind after reading up on it, so I'd have read
up on this again to answer this.

> set using link format and then retrieved using CoRAL?

We should go through the list of known attributes [1] at some point
and decide for each how the information should be expressed in CoRAL.
The current idea is to define vocabulary that corresponds to these
attributes, but not to define a mapping that round-trips in the
presence of unknown attributes. For "obs", I guess a link relation
type like <http://coreapps.org/reef#obs> with a bool as link target
would make sense.

Klaus

[1] https://hackmd.io/AfjWKj7rRDiQl16WSSIa4w?both

---

From: Jim Schaad <[email-masked]>
Date: Tue, 16 Jul 2019 11:37:25 -0700

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Tuesday, July 16, 2019 10:44 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]; core <[email-masked]>
Subject: Re: [core] draft-hartke-t2trg-coral and reef

Hi Jim!

> CoRAL:
>
> 1.  When applying a dictionary, is the expanded value always treated 
> as a string or is it a typed item.  The difference would be if you 
> matched both "0" and 0 when doing the conversion between the representations?

[JLS] Good that was my guess.

> 2.  Are dictionaries applied to each element in a CIRI or just to the 
> CIRI as a whole?

draft-hartke-t2trg-ciri-03 doesn't make use of dictionaries at all; a CIRI itself cannot refer to a dictionary entry.

draft-hartke-t2trg-coral-09 allows you to put a dictionary key in certain places where a whole CIRI is expected.

That's how it's currently specified. The current idea is to build up a small repository of real-world examples and then revisit the whole topic of compressing duplications in a CoRAL document.

> 3.  I think the answer to this is going to be it does not matter, but 
> does a CIRI need to be made absolute prior to doing the dictionary 
> lookup? The reason why I say this is that it would be really 
> unexpected to have a prefix URI in a dictionary that would match a 
> CIRI as a target where the target is relative to the current node.

draft-hartke-t2trg-coral-09 only really tells you what it means when a recipient sees a dictionary key in a document. It's up to the generator to decide how it puts dictionary keys into it.

I think it might be useful to have some relative references in the dictionary. For example, I could imagine you might want to link to </.well-known/core> relative to the current resource.

[JLS] One might way that both should be made absolute to the "current context" and replace only if they then compare.  I am not sure that you want to do the replacement if they are not going to be the same.  It may be that this is not something that makes a practical difference.  I will have to play with this some to figure it out.

> 3.  What happens for a parser if the generator used a newer version of 
> the dictionary than it has?  Thus there is an element 22 and I cannot 
> understand it.

It's indeed undesirable if extending a dictionary with new entries breaks consumers using an older version.

This is one of the blocking issues that needs to be solved. I don't have a good idea yet.

[JLS] Neither do I.

> Reef:
>
> 1.  Is the Resource Metadata in section 3 missing "reef#ep" ?  Looking 
> at some of the examples - has the idea of an endpoint name and a 
> domain just vanished?

In general, the draft doesn't try yet to exhaustively replicate all the features of draft-ietf-core-resource-directory-23 (due to lack of time mostly).

The idea of endpoint name and domain is something that somehow always immediately escapes my mind after reading up on it, so I'd have read up on this again to answer this.

> 2.  What is the correct behavior for an attribute such as "obs" when 
> it was set using link format and then retrieved using CoRAL?

We should go through the list of known attributes [1] at some point and decide for each how the information should be expressed in CoRAL.
The current idea is to define vocabulary that corresponds to these attributes, but not to define a mapping that round-trips in the presence of unknown attributes. For "obs", I guess a link relation type like <http://coreapps.org/reef#obs> with a bool as link target would make sense.

[JLS] This matches what I did.  That is relations which are not full URLs are going to be suppressed.  Of course I would apply some type of mapping for known attributes.

Jim

Klaus