On 29/01/2019 2:25 am, Kimball, Adam wrote:
Holger,
Thanks for the timely response.
For now, a simple rdfs:label solution would be OK. My triples are
being generated via an ETL and represent factual statements about the
past. Given that, I don’t have too much of a concern for using a
label at triple-generation time.
As for alternative methods, I am definitely interested in SHACL rules
- mostly to get some experience with them because I’ve long wanted
this functionality and any experience working with them would be good.
Can we get a webinar or even a blog post about the use of SHACL rules
within the TopBraid platform?
See discussion off-list.
Yes, your example from owl:Time is right for me. The only thing
different is that the B-Node can be either an interval or an instant
depending upon the source data from which the triples derived.
I was curious myself so I created a small demo of how such rule could
look like to compute labels for such bnodes. The files are attached. May
look a bit geeky without background knowledge, but you should be able to
play with this if you open the example file in TBC and press the run
inferences button:
If you import the rules file into an EDG Ontology and go to Reports >
Property Value Rules, you can see a visualization of the rules:
This illustrates how these rules work: imagine the data flowing from
left to right, with each step doing a further transformation. The upper
rule computes the label by converting the value of time:inXSDDateTime to
a string using the SPARQL str operator. The lower rule then concatenates
the labels of hasBeginning and hasEnd and wraps them into [ ... , ... ].
The rules evaluate recursively, i.e. the labels of the Time Instant
objects are computed when needed for the labels of the Time interval.
(If you don't want to use these expression-based SHACL rules, you can
use sh:sparql to compute labels in SPARQL.
TBC renders such rules as
So while this is working in principle (to compute the rdfs:labels), the
values are actually not used on forms if used in references. So an
object property pointing at the specific time interval instance would
not compute the label dynamically yet, in 6.1. I have however just added
support for such dynamically computed labels to 6.2.
(To anyone discovering this thread from a time machine, archive or so,
after 6.2 came out, note that you need to add a graphql:name
"rdfs_label" to any property shape on rdfs:label because it would
otherwise clash with the hard-coded GraphQL "label" field.)
I can wait until 6.2 for the label functionality to work..
Meanwhile, if your data is generated anyhow, you could potentially turn
the time objects into URIs, where rdfs:labels are already used in 6.1
and earlier. 6.2 does use them for bnodes too.
Holger
-Adam
On Jan 27, 2019, at 4:59 PM, Holger Knublauch <[email protected]
<mailto:[email protected]>> wrote:
CAUTION:This email originated from outside of the organization. Do
not click links or open attachments unless you recognize the sender
and know the content is safe.
Hi Adam,
that's a good question, and a recurring issue. In 6.2 (which is
consistently based on the new GraphQL-based API and SHACL), the label
of blank nodes are derived consistently with other (named) resources:
by their rdfs:label (or skos:prefLabel and other sub-properties of
rdfs:label). So one approach - if possible - would be to have
rdfs:labels in the blank nodes. That solution, however, would be best
automated, e.g. by periodically executing rules to compute the
rdfs:labels. For better or worse, at this stage, rdfs:labels that are
backed by rules would not be computed on the fly as this would have
some negative performance implications. So for now, rdfs:labels would
need to be either periodically updated by rules, or maintained by hand.
Of course, the generation of rdfs:label values is somewhat redundant
and brittle (in case the underlying triples change but the labels do
not). Custom view widgets in SWP remain a possibility and will
continue to work. They offer the greatest flexibility even for
complex objects such as OWL time intervals. Use tosh:viewWidget to
point at a custom widget.
As nothing is cast in stone yet (for 6.2 and beyond), I'd like to
evaluate whether this can be further improved. For example, labels
could be computed using SHACL property value rules
https://www.topquadrant.com/graphql/values.html
I am not familiar with the OWL time ontology, but is the following a
typical use case for you?
ex:MyEvent
a ex:Event ;
rdfs:label "My Event" ;
ex:duration [
time:Interval ;
time:hasBeginning [
a time:Instant ;
time:inXSDDate "1971-07-07"^^xsd:date ;
] ;
time:hasEnd [
a time:Instant ;
time:inXSDDate "2020-01-04"^^xsd:date ;
]
] .
and maybe you would want such objects to be rendered as
My Event
duration: [ 07/07/1971 - 01/04/2020 ]
(The example highlights the apparent need for internationalization,
arguing that rules should compute different values for @en-US than
general @en where the date format is more regular. This of course
further complicates the solution and would further impact performance
if all those values are to be computed at display time).
Holger
On 26/01/2019 3:09 am, Adam Kimball wrote:
Hi all,
I have a dataset where owl:time is used to describe both intervals
and instants. When I come across these b-nodes in EDG, they are
rendered in shaded boxes and really stand out. Although I derive
info from this layout, most of our users won't.
I'm wondering how I might override the rendering, ideally with the
use of a shape. For instance, if the b-node is time:Interval then
show begin/end if it is an time:Instant just show that one time. I
could probably hack together a SPIN/SWP solution but I think the UI
has moved on from this. What's the recommendation? Any system
usages I might want to examine?
Thanks,
Adam
--
You received this message because you are subscribed to the Google
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email [email protected]
<mailto:[email protected]>.
For more options, visithttps://groups.google.com/d/optout
<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=c31WRmngRl-Ei5FxoVl5JYQYy1t5NE6gKgMbp1GhG5M&m=jEAjkPiZcnEbQLst_zm3rvTeMHePawK9ib9ZxcAW21c&s=pytpKEkETzK11VA7shVDxqAs9PqititPVSHWRNWaeYA&e=>.
--
You received this message because you are subscribed to the Google
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email [email protected]
<mailto:[email protected]>.
For more options, visithttps://groups.google.com/d/optout
<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=c31WRmngRl-Ei5FxoVl5JYQYy1t5NE6gKgMbp1GhG5M&m=jEAjkPiZcnEbQLst_zm3rvTeMHePawK9ib9ZxcAW21c&s=pytpKEkETzK11VA7shVDxqAs9PqititPVSHWRNWaeYA&e=>.
--
You received this message because you are subscribed to the Google
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TopBraid
Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
# baseURI: http://example.org/timeLabelExamples
# imports: http://example.org/timeLabelRules
# prefix: timeLabelExamples
@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 timeLabelExamples: <http://example.org/timeLabelExamples#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://example.org/timeLabelExamples>
a owl:Ontology ;
owl:imports <http://example.org/timeLabelRules> ;
owl:versionInfo "Created with TopBraid Composer" ;
.
timeLabelExamples:exampleInterval
a <http://www.w3.org/2006/time#Interval> ;
<http://www.w3.org/2006/time#hasBeginning> [
a <http://www.w3.org/2006/time#Instant> ;
<http://www.w3.org/2006/time#inXSDDateTime> "2010-01-02"^^xsd:dateTime ;
] ;
<http://www.w3.org/2006/time#hasEnd> [
a <http://www.w3.org/2006/time#Instant> ;
<http://www.w3.org/2006/time#inXSDDateTime> "2011-04-06"^^xsd:dateTime ;
] ;
.
# baseURI: http://example.org/timeLabelRules
# imports: http://datashapes.org/dash
# imports: http://datashapes.org/graphql
# imports: http://datashapes.org/sparql
# imports: http://www.w3.org/2006/time
# prefix: timeLabelRules
@prefix dash: <http://datashapes.org/dash#> .
@prefix graphql: <http://datashapes.org/graphql#> .
@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 sh: <http://www.w3.org/ns/shacl#> .
@prefix time: <http://www.w3.org/2006/time#> .
@prefix timeLabelRules: <http://example.org/timeLabelRules#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://example.org/timeLabelRules>
a owl:Ontology ;
owl:imports <http://datashapes.org/dash> ;
owl:imports <http://datashapes.org/graphql> ;
owl:imports <http://datashapes.org/sparql> ;
owl:imports <http://www.w3.org/2006/time> ;
owl:versionInfo "Created with TopBraid Composer" ;
.
time:Instant
a sh:NodeShape ;
sh:property [
a sh:PropertyShape ;
sh:path rdfs:label ;
graphql:name "rdfs_label" ;
sh:datatype xsd:string ;
sh:values [
<http://datashapes.org/sparql#str> (
[
sh:path time:inXSDDateTime ;
]
) ;
] ;
] ;
.
time:Interval
a sh:NodeShape ;
sh:property [
a sh:PropertyShape ;
sh:path rdfs:label ;
graphql:name "rdfs_label" ;
sh:datatype xsd:string ;
sh:values [
<http://datashapes.org/sparql#concat> (
"["
[
sh:path rdfs:label ;
sh:nodes [
sh:path time:hasBeginning ;
] ;
]
", "
[
sh:path rdfs:label ;
sh:nodes [
sh:path time:hasEnd ;
] ;
]
"]"
) ;
] ;
] ;
.
