Re: [EXT] Re: [spdx-tech] SPDX IDs - internal or meaningful?
It does make sense. If SPDX accepts it as a valid design requirement, it also means that we MUST define a URI profile that uniquely identifies the boundary between namespace, document-supplied ID, (and hopefully, hint) without using fragments. That's doable, but to be useful it would have to be accepted at a higher level than SPDX, e.g., by the communities that want to do SPARQL processing. Have any of them proposed such a boundary-detection scheme? |
Sorry for any confusion.
By "fragment-based ID" I meant any ID containing “#” character which is interpreted as a resource fragment in the URI structure.
In URI structure, any URI containing a “#” character is explicitly asserting that the preceding content in the URI is the primary resource and the succeeding content (the fragment) is a sub-resource subservient to (typically contained within) the primary resource.
In HTTP only the primary resource (content preceding the #) is considered. Fragments are explicitly only processed client side and are not processed server side. This includes that they are not considered in http redirects.
Linked data (which I would propose is the likely most common eventual future for data sharing and certainly within the use case scope for SPDX 3.0) relies on IDs being URIs/IRIs that are http resolvable including the ability to support redirection. Rather than the end of an http Get or Post being a web server serving back content, it could be a SPARQL endpoint exposed for external interaction and that SPARQL endpoint can make content (Element, Elements or even graphs of Elements) directly accessible especially for automation. This is extremely powerful for many reasons we can discuss as a group if desired.
In such interactions content (Elements) are independent of any Document AND relies on Element identifiers being valid URIs/IRIs without fragments.
Does that make sense?
sean