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
PURLs created under 1.4 will not work under 1.5. I think there are 2 issues that possibly needed to be dealt with during migration:
The Purl class is intended for simpler cases and perhaps existing PURLs (or at least those matching certain criteria need migrating to RewriteRules to maintain functionality.
There has been a change in the way the regex is applied between 1.4 and 1.5. It now only applies to the URI beyond the PURL itself whereas in 1.4 it applied to the whole URI.
For example:
<company-rdf> a calli:Purl , </callimachus/1.4/types/Purl>
; calli:copy "^[^\?]+\?id=.*$ /usepa/app/pipelines/company-data.xpl?results&id={id}\nAccept: application/rdf+xml"^^xsd:string
; rdfs:comment "Proxies RDF/XML from the FRS SPARQL endpoint for a company."^^xsd:string
; rdfs:label "company-rdf"^^xsd:string .
The only change in migration was the Purl type becoming </callimachus/1.5/types/Purl>.
When you edit this you cannot see the regex expression and the Accept header is treated as part of the target URL - the line break becomes a space.
In the case above the PURL can be replaced with a simple Purl without any regex expression and a target of /usepa/app/pipelines/company-data.xpl?results&id={id} as the query parameters are already parsed out of the query string
It may not be possible to do any automatic migration but we at least need to document the issues
The text was updated successfully, but these errors were encountered:
PURLs created under 1.4 will not work under 1.5. I think there are 2 issues that possibly needed to be dealt with during migration:
For example:
The only change in migration was the Purl type becoming </callimachus/1.5/types/Purl>.
When you edit this you cannot see the regex expression and the Accept header is treated as part of the target URL - the line break becomes a space.
In the case above the PURL can be replaced with a simple Purl without any regex expression and a target of
/usepa/app/pipelines/company-data.xpl?results&id={id}
as the query parameters are already parsed out of the query stringIt may not be possible to do any automatic migration but we at least need to document the issues
The text was updated successfully, but these errors were encountered: