You can use a magnet or ipfs uri or add a triple that specifies other properties of the file that let you find it.
Semantic web uses IRIs in triples. They serve as identifiers, not locators (URL). This is because semantic web talks about more than just files.
The Web Annotation spec talks about web resources which should be dereferencable. That is a naive assumption that makes the approach brittle. But one can annotate 'sourceDate' and 'cached' which indicate the date for the annotated version and a location for a copy.
When you're annotation a resource it's best to also store a copy. The Web Annotations specification allows this.
It's preferrable to use the ni:// URI scheme since it is standardized, unlike magnet links. There is a draft standard https://datatracker.ietf.org/doc/html/draft-hallambaker-deca... defining common extensions that enable much the same featureset as magnet.
> When you're annotation a resource it's best to also store a copy
Do you know if there's any precedent re: people getting upset about that copy? If I annotate an article that was originally served with ads, or behind a paywall, I'll probably not include that stuff in my copy. If people then start linking to my copy instead of the original, I could imagine that feathers would be ruffled.
If you're not permitted to publish a copy, you can keep it private and/or link to a version at an institution, such as archive.org, that is allowed to keep a public copy.
Semantic web uses IRIs in triples. They serve as identifiers, not locators (URL). This is because semantic web talks about more than just files.
The Web Annotation spec talks about web resources which should be dereferencable. That is a naive assumption that makes the approach brittle. But one can annotate 'sourceDate' and 'cached' which indicate the date for the annotated version and a location for a copy.
When you're annotation a resource it's best to also store a copy. The Web Annotations specification allows this.