Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add UUID generator incorporating dictionary entry keys #164

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions case_utils/inherent_uuid.py
Original file line number Diff line number Diff line change
Expand Up @@ -96,6 +96,15 @@
)


def dictionary_entry_inherence_uuid(
uco_object_uuid_namespace: uuid.UUID, key_name: str, *args: Any, **kwargs: Any
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why accept *args and **kwargs if they're silently ignored?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. These were my suggestion, so I'll field the question.

This addresses a syntax in Python's function definitions that frequently looks ambiguous to me, where a kind-of-positional spelling can be used at call time.

I've found it helpful to have at least *args always, as a reminder that there's a point in the argument list where the arguments are no longer positional. If it comes at the end, great! All arguments are positional. **kwargs tends to come along as a matter of habit - if there's *args, I tend to want **kwargs as well.

I also include *args and **kwargs in class methods when I know subclasses are going to override the implementations, or use super().

So, by two habits, I use *args and **kwargs in function definitions, and I suggested those to @sldouglas-nist .

) -> uuid.UUID:
"""
This function returns a UUIDv5 for dictionary entries, incorporating the key string's value.
"""
return uuid.uuid5(uco_object_uuid_namespace, key_name)


def inherence_uuid(n_thing: URIRef, *args: Any, **kwargs: Any) -> uuid.UUID:
"""
This function returns a UUIDv5 for any OWL Thing, that can be used as a UUID Namespace in further `uuid.uuidv5` calls.
Expand Down Expand Up @@ -152,6 +161,47 @@ def facet_inherence_uuid(
return uuid.uuid5(uco_object_inherence_uuid, str(n_facet_class))


def get_dictionary_entry_uriref(
n_dictionary: URIRef,
n_dictionary_entry_class: URIRef,
key_name: str,
*args: Any,
namespace: Namespace,
**kwargs: Any
) -> URIRef:
"""
:param namespace: An RDFLib Namespace object to use for prefixing the Dictionary IRI with a knowledge base prefix IRI.
:type namespace rdflib.Namespace:

:param n_dictionary_entry_class: Assumed to be a "Proper Dictionary", as defined in UCO Issue 602.

References
==========
* https://github.com/ucoProject/UCO/issues/602

Examples
========
A dictionary has to have an entry with key "foo". What is the IRI of the dictionary entry?

>>> from case_utils.namespace import NS_UCO_TYPES
>>> ns_kb = Namespace("http://example.org/kb/")
>>> n_dictionary = ns_kb["Dictionary-eb7e68d8-94db-4071-86fa-a51a33dc4a97"]
>>> n_dictionary_entry = get_dictionary_entry_uriref(n_dictionary, NS_UCO_TYPES.DictionaryEntry, "foo", namespace=ns_kb)
>>> n_dictionary_entry
rdflib.term.URIRef('http://example.org/kb/DictionaryEntry-6ce6b412-6a3a-5ebf-993a-9df2c80d2107')
"""
uco_object_uuid_namespace: uuid.UUID = inherence_uuid(n_dictionary)
dictionary_entry_uuid = dictionary_entry_inherence_uuid(
uco_object_uuid_namespace, key_name
)

dictionary_entry_class_local_name = str(n_dictionary_entry_class).rsplit("/")[-1]

return namespace[
dictionary_entry_class_local_name + "-" + str(dictionary_entry_uuid)
]


def get_facet_uriref(
n_uco_object: URIRef,
n_facet_class: URIRef,
Expand Down
Loading