Serialization shows only partial substitution of namespace.

[dannmartens]

I noticed something strange when serializing a graph to turtle, after binding a namespace prefix in code, the output shows a mix of prefix notation and full IRIs. I am using 4.2.2. While developing this part of the app, I noticed that in the output, the substitution comes and goes in an unpredictable manner.

In code:

graph.namespace_manager.bind('mbse', URIRef('http://example.com/onto/v1/mbse#'))
graph.namespace_manager.bind('requirements', URIRef('http://example.com/api/v1/requirements/'))

Now, look at the "requirements" prefix:

@prefix co: <http://purl.org/co/> .
@prefix mbse: <http://example.com/onto/v1/mbse#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix requirements: <http://example.com/api/v1/requirements/> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example.com/api/v1/requirements/92c6e875-c721-4b2c-82ab-076de020d97e> a mbse:Requirement,
        owl:NamedIndidual ;
    co:member <http://example.com/api/v1/requirements/131fe437-5b49-4ab0-bee5-5ad5b0aa7a2f>,
        <http://example.com/api/v1/requirements/238f0f5d-28d6-4349-861d-d1d3a0cb3ce6>,
        <http://example.com/api/v1/requirements/42d6cd38-6858-48a8-88a6-db886eaf3bea>,
        <http://example.com/api/v1/requirements/4e33d5ee-5494-48a6-8aaa-d86240eecfbe>,
        <http://example.com/api/v1/requirements/5990ebbb-7023-4a4e-9bb6-34aff2bb6599>,
        <http://example.com/api/v1/requirements/708ef762-0c7e-4a11-84a3-4f84ddd28d42>,
        <http://example.com/api/v1/requirements/78ea66bc-ff55-4ffc-8c3d-a931c52e6811>,
        <http://example.com/api/v1/requirements/7e24a77f-cf1b-4285-b53b-e86230927a74>,
        <http://example.com/api/v1/requirements/8e410082-b85b-4184-8728-75f404415469>,
        requirements:a130d8ff-4482-4ffa-89c1-93da3e9fdf75,
        requirements:f384f799-4eac-44f2-b131-c1d47672fb55,
        requirements:f5252fbf-fe18-4959-a4a5-1a9b7b18dd0b,
        requirements:ff701a5d-dad6-41e8-8601-6651826245d4 .

Only a few are substituted: I can't make any sense of this behaviour.

[white-gecko]

Can you please write a test for this and submit the test as pull request?

[niklasl]

It seems that in the example, the prefixed form only occurs where the local part begins with a letter (and conversely the UUID:s in the full URI:s begin with a digit).

[dannmartens]

@niklasl You're right, I did not notice that before. Great catch!

That would explain why it appeared to come and go in some of my tests, where the UUIDs were generated on the fly.

[tgbugs]

This should already be fixed in master I think.

[white-gecko]

In which commit, PR?
Do we have a test to prevent regression?

[tgbugs]

Fairly sure this should have done it 348e8dc as part of #649, and I think I added a regression test, but that may be in my tests for deterministic behavior in another repo.

[dannmartens]

With v5.0.0, I see that the UUIDs are properly prefixed, regardless of the value, starting with either a letter or a digit. However, now none of the URN-based prefixes are substituted. They don't even show up in the prefix declarations. I checked my code: they are bound with the namespace manager. I even tried some explicit hard-coded bindings, to no avail. I'll continue to investigate to see if my code could be at fault. Maybe I overlooked something.

…

On Wed, May 27, 2020 at 11:57 AM gauri-b ***@***.***> wrote: Has a solution already been incorporated for this issue? or is it still open? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#977 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACAHXJGNJB7G2EJWGXHPPLRTTPXJANCNFSM4LOPL7PA> .

[tgbugs]

Do you have examples of the URN issue?