-
Notifications
You must be signed in to change notification settings - Fork 10
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
OSLC Link Discovery Management - support reverse link lookup #600
Comments
I think reverse link lookup is raison d'être for LDM. Let's assume there is a link somewhere in the system of the form: <https://system_a/resource_a> oslc_rm:elaborates <https://system_b/resource_b> . System B is expected to make a query to LDM of the following type: ?s oslc_rm:elaborates <https://system_b/resource_b> . or even ?s ?p <https://system_b/resource_b> . Is this the kind of lookup you wish to skip? Or are you proposing to skip the |
LDM should only do what the client asked for. That allows those clients to determine what they want to do with sameAs and inverses, both are things not supported by OSLC.
From: MartinUlrich ***@***.***>
Date: Tuesday, September 5, 2023 at 12:50 PM
To: oslc-op/oslc-specs ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [EXTERNAL] [oslc-op/oslc-specs] OSLC Link Discovery Management - support reverse link lookup (Issue #600)
Links are replicated to LDM in the format: subject, predicate, object. The LDM service shall use the predicate (e. g. satisfies) for filtering and in the triples returned. An alternative approach could be, that LDM translates the predicate in
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!2q-qKtX1KRJyuc5TswsmJg8aP5xY6VrXOByk0jbFHKwG9ugtujuXcBa4V4EVZ5-JrtiuvhT8jQ2qm0hL6OwQe3k$>
ZjQcmQRYFpfptBannerEnd
Links are replicated to LDM in the format: subject, predicate, object. The LDM service shall use the predicate (e.g. satisfies) for filtering and in the triples returned.
An alternative approach could be, that LDM translates the predicate in to the reverse predicate (e.g. satisfied by), in order to consider the reverse predicate for filtering and in the triples returned.
Proposal is not to support reverse link lookup.
Rationale:
* LDM should not know anything about the semantics of the predicates, to keep the service simple
* semantics of predicates can easily be managed by the clients
—
Reply to this email directly, view it on GitHub<#600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAIQFKQ44P425VKOBOBJ5ILXY5J4PANCNFSM6AAAAAA4MCAF7Y>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Searching for the inverse property shall be skipped. |
I agree with Jim - it is up to clients to specify the link types and target URIs, and LDM should only do what the client asks. |
Links are replicated to LDM in the format: subject, predicate, object. The LDM service shall use the predicate (e.g. satisfies) for filtering and in the triples returned.
An alternative approach could be, that LDM translates the predicate in to the reverse predicate (e.g. satisfied by), in order to consider the reverse predicate for filtering and in the triples returned.
Proposal is not to support reverse link lookup.
Rationale:
The text was updated successfully, but these errors were encountered: