Meeting minutes
Guests
<kaz> (Christine is a guest today, and Kaz confirms she is aware of the PP)
Prev minutes
no objections to publishing the minutes
approved
PR 108
PR 108 - apply the diff with the FPWD version
Kaz: objections to merge this?
(none)
(merged)
joint call with the Spatial Data on the Web
Kaz: joint call with the SDW-IG/AR next Monday, Jan 18
… the Discovery call
<kaz> Sorry but actually the joint call will be held Tuesday, Jan 19 at 11am US Eastern as a separate call
<kaz> Please see also Kaz's message sent to the Members list for the meeting details
PR 107
https://
Kaz: will wait for McCool to address Andrea's concern
Issue 98
https://
Farshid: we suppose to confirm which proposal is more preferable
Farshid: some people have already voted
Cristiano: what information will be included? Will it be standardized?
Farshid: it will be just registration data. We can decide later if this will be mandatory.
Andrea: can we extend the model to include metadata for filtering items?
Farshid: we have the type for "Directory" but not yet added to TD context. See https://
Cristiano: it may be better to define a separate context for TDD instead of adding the class or other vocab to TD's context
Kaz: Farshid, can you generate a PR for this?
Farshid: would like to think about Issue 34 on links as well
Issue 34
<kaz> Issue 34 - Add links section to directory information model
Farshid: need to pick an appropriate relation type
Farshid: e.g., describedby from https://
Koster: we could pick a registered type, e.g., describedby
Koster: i think there is a type for collections which may be a good option
Kaz: if we define this, we need to make sure other processors understand it
Farshid: will create a PR including the link and TD models inside TDD. Will use describedby relation type instead of furtherExploration as it is registered.
<cris_> +1 for Koster's proposal. collection rel type fits well in my opinion
Koster: allowing multiple relation types is a good idea and very useful in directories. It also relieves us from the burden of trying to choose one.
Kaz: I agree.
Kaz: we can go with describedby and then look into alternatives such as "collection" and "item" based on some concrete use case and flow.
Koster: describedby is intended for pointing to another resource, describing a resource through certain mean. It could even be pointing to some openapi spec.
Farshid: we can combine it with the content type to specify how the resource is described.
Koster: I agree, the generic describedby relation type can be used appropriately in different use cases.
Issue 104
<kaz> Issue 104 - Canonicalization requirements for directories
Andrea: we don't have an appropriate framing document. Have reached out to Sebastian and he is looking into it.
Cristiano: have you tried to implement anything to address framing?
<kaz> Andrea's updated comments
Andrea: i am experimenting. I have tried a JSON-LD 1.1 library and got some input from the maintainers of that library.
Andrea: the problem is not the conversion, but the lack of the frame to do it.
Kaz: maybe talking with the DID-WG guys would be helpful given the JSON-LD WG is in a maintenance mode.
Kaz: let's continue the discussion during the next Discovery call and also possibly during the TD call.
[adjourned]