-
Notifications
You must be signed in to change notification settings - Fork 23
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
Gather the Use Case and Requirements for RDF* #29
Comments
As a data engineer, So that I do not need to transform the property into a relation+ yet another node. |
As an ontologist/schema developer using SHACL (This use case is already implemented in our TopBraid EDG product) |
As a data service, from an architectural perspective, interpretation should be distinct from and cleanly layered over representation - both abstract and concrete, in order to facilitate implementation and assure the ability to support future use cases as knowledge evolves over time. From this perspective, the standard treatment of blank node labels is an anti-requirement, the lessons of which should dissuade from unnecessarily restrictive relations between interpretation and representation. |
Could you please explain the use case in a way I can immediately understand? Thanks ;-) |
the situation with blank node labels is a case where the interpretation was fixed, to treat them as referentially opaque. that was a mistake. it would have been better to separate the interpretation from the representation and to allow alternatives. |
As a member of the Wikidata community I would like to see triple stores supporting the Wikidata/Wikibase data model as much as possible, so that provenance information etc. can be represented in a way which is pleasing to the mind and software-systems such as Wikibase. See: |
As a materials scientist working with ontologies |
As a data engineer |
As an analyst |
As a knowledge worker |
does this require that you be able to annotate quads? |
I assume so, yes |
I want to annotate commit deltas to an RDF graph, e.g.:
So that a triple can be searched for across commit history in SPARQL*. |
As a KG vendor, we want Stardog customers to have easy to use means to attach properties to edges in their RDF graph or load property graph data with edge properties. Here "easy" specifically means that neither the customer nor the database should have to wreck the data model (and queries) to use any of the workarounds available in plain RDF for that purpose (like the RDF reification). For example, if the customer has |
does this intend the that, beyond the "in any name graph" requirement, you intend to be able to distinguish between otherwise identical triples in distinct named graphs? |
No, I only meant that we do not want to use the graph IRI on the statement level to link edge properties to that since in most cases we see it's already used for named graphs. Grouping triples together and adding properties to individual triples are different use cases for us most of the time. |
yet, is it not true that, any distinction between those use cases notwithstanding, the graph identifier will have to either qualify the identity of the triple, in which case one is annotating quads, or otherwise qualify the scope over which the reference applies, which amounts to the same? |
I am not sure I understand the question and also I don't think this ticket was created to discuss use cases but to list them. So we should probably stop and continue wherever each use case is going to be discussed. |
We have a number of use-cases already in this thread, which is great! So I created a label @afs @gatemezing @HolgerKnublauch @lisp @akuckartz @mospring @rat10 @blake-regalia @klinovp |
Just to say thank you to everyone who has put a use case on this issue and also that it won't be forgotten even if not made a separate issue. |
It helps keeping track of the submissions if we can use GH labels. I've put all the use cases into the doc https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html including ones that only on this issue (subject to editorial mistakes of course). Now that hey are captured, this issue shouldn't be used for new use cases. |
It seems that this issue should be closed, with an advisory template for creation of new issues, each new issue to contain one new use case, for the initial work of clarification and de-duplication if/as needed; and an equally important advisory link to the UCR doc source against which additional issues and PRs may be logged, toward the output report/doc? (It's unclear to me what the relationship between that and EasierRDF-RDFStarUCandRequirements.html; perhaps that could be clarified as well?) |
@TallTed : templates already done. And please read: |
@afs -- re: previous-material -- please see #54 re: templates -- I was suggesting that the new-UCR-issue template (#29 (comment)) be repeated in a closure post to #29, which post should also include a link to the current UCR doc. Idea being, minimize the detective work new participants/contributors/visitors need to do to figure out those things. |
issue #29 is not the only one related to UCS anymore
issue #29 is not the only one related to UCS anymore
This issue is to collect together the use cases for RDF*.
Please add use cases you are aware of as comments below.
The document started in EasierRDF has been copied into this repo and is visible as HTML at:
https://w3c.github.io/rdf-star/UCR/
Recording a UC&R is not a promise by the CG to address that use case.
A useful format is:
The text was updated successfully, but these errors were encountered: