@bergos will you have async version of clownface? i rolled up something similar in https://github.com/valueflows/vf-track-trace.ts/blob/master/index.ts#L34-L43 which eventually should work with TPF client and query store over the network
that code uses ES async iteration and
for - await - of loop to traverse data
@pietercolpaert graphy does this by default for XSD datatype-specific values like you mentioned, for example, parsing
"42"^^xsd:integer from a Turtle document yields a Literal_Integer, and the numeric value is available as term.number while the string remains at term.value
@elf-pavlik actually I recall now it only applies to syntactic numerals e.g.,
42 or 3.14159 so that it doesn't have to handle parsing errors; numeric_literal()
this part is also relevant for casting @elf-pavlik https://github.com/blake-regalia/graphy.js/blob/master/src/core/data/factory.js.jmacs#L366
I'm using the topbraid shacl-js library. It's a bit buggy and quite slow.
so it should be soon released
@/all i've upgraded the rdf-body-parser package, which was actually already more then a body-parser, as it also handles sending responses. the new name is now express-handler and i put it already into the rdfjs org. it still has a rdf-ext dependency, as it relies on the
.import() and .toStream() methods of the dataset. in all other packages of the rdfjs i have only rdfjs dependencies, if a rdf related package is required. anyway i would like to release it already in the rdfjs org as it will use the rdfjs dataset once we finished the rest of the dataset spec and it don't want to create packages, which are maintained only temporary and requires people to change the dependency. any concerns? and here is the package: https://github.com/rdfjs/express-handler
anybody know if there is a repo for typescript type declarations for the three different specs on https://rdf.js.org/
I don't see them but I thought I'd check
it does not implement any of the specifications, but I think it’s important to have there anyway
if it's about using factory vs. using constructor, i think there is an older issues or log from a call.
Like one of the peculiarities is all of the interfaces have the same definition; so if the intention is that an implementation is going to expose the DataFactory, it's also going to have to expose Term, NamedNode, ect; because you have to explicitly hide interfaces with
[NoInterfaceObject] (and even then that's highly discouraged)
@awwright If I understand correctly you are saying two things:
- Why do we need DataFactory / why is it spec'd that way?
- Why isn't
[Constructor]used for the interfaces2.1to2.7?