You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Different options to implement the identifier strategy for e.g., keeping a block ID persistent:
Using just local identifiers for e.g., a block id will give 2 problems:
break federation, as multiple GTFS feeds get translated into Linked Connections and will reuse the same block IDs.
When an updated GTFS feed gets published, the block ids might conflict with the earlier version.
Suggestion solution to introduce a global identifier
https://example.org/blocks/{block_id}
Solved the problem with federating over different source, but not yet the problem of making it work when an updated GTFS file gets translated to LC (unless for your GTFS feed, block ids are incremental over time and you can rely on this).
So we need to scope it to the specific GTFS feed and this brings us to another problem: how do you identify this specific GTFS feed or the fact it got translated to RDF here.
Suggestion for a version number:
Rely on feed_version in feed_info.txt -- Design issue: don’t include patch version so that a block id stays the same when the minor and major version number didn’t change? (e.g., 1.2.0 → 1.2.1)
When the GTFS feed’s version is not set, instead use a timestamp from the moment we started gtfs2lc
URI template for e.g., block then becomes: https://example.org/blocks/{feed_version}/{block_id}
The text was updated successfully, but these errors were encountered:
Different options to implement the identifier strategy for e.g., keeping a block ID persistent:
Using just local identifiers for e.g., a block id will give 2 problems:
Suggestion solution to introduce a global identifier
https://example.org/blocks/{block_id}
Solved the problem with federating over different source, but not yet the problem of making it work when an updated GTFS file gets translated to LC (unless for your GTFS feed, block ids are incremental over time and you can rely on this).
So we need to scope it to the specific GTFS feed and this brings us to another problem: how do you identify this specific GTFS feed or the fact it got translated to RDF here.
Suggestion for a version number:
feed_version
infeed_info.txt
-- Design issue: don’t include patch version so that a block id stays the same when the minor and major version number didn’t change? (e.g., 1.2.0 → 1.2.1)gtfs2lc
URI template for e.g., block then becomes:
https://example.org/blocks/{feed_version}/{block_id}
The text was updated successfully, but these errors were encountered: