Its sad to see another PHP/RDF project being not maintained anymore. First of all, @njh and all contributors did an amazing job of creating EasyRdf. Because it is widely used (Github reports "Used by": 14.5k), there should be a way to continue its maintenance and even add further improvements.

I would love to hear from @njh, if he has plans for EasyRdf.

In case, he has no plans or doesn't react, i would suggest the following: we create a new organization and fork the repository. This would allow a wider audience to work on the code.

I can help with organizing issues, check code and other stuff from time to time.

Based on the network view there are projects with improvements, fixes, i assume. (Just to name a few @SchemaApp, @acdh-oeaw, @frmichel)

What do you guys think?

Ref: #299, #282

This fixes issue #181, tested with a JSON output and a Turtle output (the latter really shows the difference and correctness). If any more testing needs to be done before this pull request can happen I'd be glad to look if I can be of assistance.

About hardf

https://github.com/pietercolpaert/hardf developed by @pietercolpaert

For transparency: I help out with maintenance from time to time.

hardf claims to be much faster on parsing in comparison with EasyRdf or ARC2.

| #triples | framework | time (ms) | memory (MB) | |----------:|-------------------------|------:|--------:| |1,866 | Hardf without opcache | 27.6 | 0.722 | |1,866 | Hardf with opcache | 24.5 | 0.380 | |1,866 | EasyRDF without opcache | 5,166.5 | 2.772 | |1,866 | EasyRDF with opcache | 5,176.2 | 2.421 | |1,866 | ARC2 with opcache | 71.9 | 1.966 | | 1,866 | N3.js | 24.0 | 28.xxx | | 3,896,560 | Hardf without opcache | 40,017.7 | 0.722 | | 3,896,560 | Hardf with opcache | 33,155.3 | 0.380 | | 3,896,560 | N3.js | 7,004.0 | 59.xxx | | 3,896,560 | ARC2 with opcache | 203,152.6 | 3,570.808 |

Table source: https://github.com/pietercolpaert/hardf#performance

My suggestion

I would like to use hardf to replace EasyRdf code for parsing and serializing turtle, n-triples, n-quads, TriG and N3. Our API should be kept, but the code behind it could be (massively) reduced and replace by hardf pendants.

Advantages:

• We won't have to care about related parser / serializer issues anymore - more free time and less code to maintain
• It's a faster and more memory-sufficient parsing solution (its seems to be based on knowledge from N3.js)

Sure, hardf code may need some attention (e.g. coding styles) and there is currently a bug, which lead to some tests fail on PHP 7.4 (https://github.com/pietercolpaert/hardf/pull/28). But its nothing we couldn't handle.

What do you think?

CC @njh, @osma, @zozlak, @pietercolpaert

Hi,

Now that I have got version 1.0.0 out of the door, it would be really good to get some help with the future of EasyRdf. As I said in #320, I no-longer do PHP or RDF for my day job and have lots of other projects that I am interested in. So I would really like some help with maintaining EasyRdf and ensure that it has a good future.

Some of the tasks I would really like people to collaborate on:

• Help direct the future of the project
• Review issues and tag them
• Review Pull Requests
• Respond to questions on the mailing list and Stack Overflow
• Fix bugs!
• Writing documentation
• Enforce the Code of Conduct
• Updating the website
• Anything else that you think help people make the most of EasyRdf

The plan is that nobody (including myself) will be able to commit directly to the master branch and that everyone will submit changes for review via Pull Requests. Depending on how many people are actively involved in EasyRdf, GitHub will require at least one review of the Pull Request before it can be merged.

So if you would like to be added as a collaborator to the EasyRdf organisation, please comment below. Ideally you would have already contributed to EasyRdf and other open source projects.

Feedback very welcome...

Thanks!

nick.

Please note that JSON-LD is a dataset format and thus a file might contain multiple graphs. Since easyrdf doesn't support datasets AFAICT, this parser just returns the default graph and ignores all named graphs.

This closes #87.

PHP 8 got released, so I tried to see if there is already infrastructure available to test it with EasyRdf. Unfortunately I couldn't even start the tests. In this PR I would like to collect the things to do to make EasyRdf compatible to PHP 8.

First problem: Composer blocked installation because of Doctum and (one of) its dependencies, see: https://travis-ci.com/github/easyrdf/easyrdf/jobs/451389149#L207

Your requirements could not be resolved to an installable set of packages.
Problem 1
- code-lts/doctum[v5.0.0, ..., v5.2.1] require wdes/php-i18n-l10n ^2.0 -> satisfiable by wdes/php-i18n-l10n[2.0.0].
- wdes/php-i18n-l10n 2.0.0 requires php ^7.1 -> your php version (8.0.1-dev) does not satisfy that requirement.
- Root composer.json requires code-lts/doctum ^5 -> satisfiable by code-lts/doctum[v5.0.0, ..., v5.2.1].

I used php: nightly in .travis.yml.

@williamdes Are you aware of this? Any plans related to PHP 8?

Maybe also relevant: PHP 8.0 status in Travis itself, see: https://travis-ci.community/t/php-8-0-missing/10132/12

Since 1.10 (https://github.com/composer/composer/pull/8397), Composer displays a deprecation notice when installing easyrdf/easyrdf 0.9.1:

Deprecation Notice: Class EasyRdf_Parser_JsonLd located in ./vendor/easyrdf/easyrdf/lib/EasyRdf/Parser/JsonLdImplementation.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /home/pierre/.config/composer/vendor/composer/composer/src/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class EasyRdf_Serialiser_JsonLd located in ./vendor/easyrdf/easyrdf/lib/EasyRdf/Serialiser/JsonLd_real.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in /home/pierre/.config/composer/vendor/composer/composer/src/Composer/Autoload/ClassMapGenerator.php:201

I'm using AllegroGraph with EasyRDF version 0.8.0.

When I create a SPARQL query where an object has the predicate dcterms:date, I get the exception message in the issue title.

I manually modified EasyRdf_Sparql_Result to include a fall-through case for literal-typed (after the existing typed-literal case) in the newTerm function and it works. Can this be officially added to EasyRDF?

Thanks.

Hello! I was wondering if it would be possible to have multiple levels of resources belonging to a particular resource. This would be extremely useful when dealing with WebIDs (certificates). Here is an example in RDF/XML:

<cert:key>
    <cert:RSAPublicKey>
        <cert:modulus rdf:datatype="xsd:hexBinary">cfa7a8e46.......24cbf43</cert:modulus>
        <cert:exponent rdf:datatype="xsd:int">65537</cert:exponent>
    </cert:RSAPublicKey>
</cert:key>

I am not able to create cert:modulus of a specific type, as a resource of cert:RSAPublicKey. Right now I can only create a sub-resource for a main graph resource: $RSAkey = $graph->resource('cert:key', 'cert:RSAPublicKey'); but I cannot add a resource to $RSAkey.

I would like to create a new minor release to ship our latest work.

https://github.com/easyrdf/easyrdf/releases/edit/untagged-aa30be1dad1c73a5e8b3 (only for collaborators)

Content so far:

Bug fix release with a few improvements and changes in Composer dependencies.

**Highlights:**
* Composer: 
  * changed ARC2 from `~2.2` to `^2.4` (#347)
  * replaced `sami/sami` with `code-lts/doctum`
  * added the following required PHP extensions: ext-pcre, ext-xmlreader, lib-libxml
* Accept an array of properties in get/getLiteral/getResource methods, fixes #325 (#326)
* Add support for parsing large SPARQL XML Results (#357)

**Highlights for EasyRdf developers:**
* added .editorconfig (#340)
* added a basic Docker setup to improve local development and testing (#334)
* added `CONTRIBUTING.md`

As far as I can see there are a few things to do before the release:

• [x] adapt milestones
• ~~based on composer.json this lib requires "ext-mbstring" ~~which isn't part of PHP 8 anymore (and might cause errors)~~ We could replace it with symfony/polyfill-mbstring to allow support for all available PHP versions (7.1+)~~

What do you think?

CC @njh @osma @zozlak

RDF* was adopted by most major RDF vendors during 2019-2020, facilitating the processing of reifications such as

<<:George :workedAt :IBM>> :during 2020 .

It would be nice if the feature would find its way in RDF libraries as well.

This pull request is a systematic approach to the EasyRdf PHP 8.1 compatibility issues. Instead of depending solely on tests, a static code analyzer phpstan has been used to detect all incompatibilities.

As a side effect fixes for other problems reported by the code analyzer have been provided like making docstring type hints in line with the code, resolving broken inheritance of ARC/JSON and RdfPhp serialisers/parsers, declaring few undeclared class properties, etc.

Last but not least examples and example tests have been fixed both for PHP 8.0/8.1 incompatibilities and for changes in the data they rely upon so that make test reports no errors nor warnings.

It's worth noting the adjustments required for the PHP 8.1 compatibility introduce backward-incompatible API changes. ArrayAccess interface offsetSet() and offsetUnset() methods must return void while in EasyRdf they sometimes returned a value. I don't expect it to affect many users and this behavior hasn't been covered by tests but it means an EasyRdf release incorporating this pull request will require EasyRdf major version bump.

Hi @njh,

Thanks very much for work on this great library.

I'm using EasyRdf to create graphs from php code. Mainly using methods Graph::resource(), Resource::addResource(), Resource::addLiteral(), etc.

It seems to me that I cannot instantiate a Collection node in the same way.

This issue request to have a method to create a Collection node in the graph and allow to add/remove items from the collection.

The ttl parser seems to fail when a property has . in it's name.

Tested with converted

@prefix :      <http://example.com/entities#> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix Resources: <http://example.com/Resources#> .
<https://example.com/data/Report/40b98c1d-9f2e-4914-828f-6b9dc9002523>
        a       :Report ;
Resources:Report.conclusion   "Not great!"@en-us
.

Error! Turtle Parse Error: object for statement missing on line 7, column 19

Removing the . from Report.conclusion => Reportconclusion or removing prefix => <http://example.com/Resources#Report.conclusion> and everything works...

Any ideas?

Currently when you serialize as JSON or JSON-LD types, the output ends up as a single line of text; It'd be great to make use of the JSON_PRETTY_PRINT flag to json_encode to pretty print the output.

I believe we'd need to add https://github.com/easyrdf/easyrdf/blob/main/lib/Serialiser/Json.php#L73 (I'm not sure what the equivalent would be for JSON-LD)

This would make it easier to read the output JSON — currently I have to copy it and then do pbpaste | jq in my terminal to read it.

I want to serialized a graph in JSONLD with the option of framing with a frame like this

      $frame = (object) [
            '@context' => 'https://schema.org/',
            '@type' => 'schema:LodgingReservation',
            (object) [

            ],
        ];

to have a "@context" : "https://schema.org/" in my JSONLD for Google to recognize because I already try to do with

  $frame2 = (object) [
            '@context' => (object) [
                     'schema' => 'https://schema.org/',
            ],
            '@type' => 'schema:LodgingReservation',
            (object) [

            ],
        ];

but Google don't recognize the JSONLD generated. With the first frame, the JSON generated is "{"@context":"https://schema.org/" ,"@graph":[]}" and the second frame, the JSONLD generated is {"@context":{"schema":"https://schema.org/"},"@graph":[ data graph ]} .

To avoid this I have to use 2 frame and 2 graph where for the first graph I serialized with a frame with the context alone and for the second graph I serialized with the $frame2 and after I use json_decode on the 2 JSONLD to transform them in array. Now, with the array I do a array_slice to remove the '@context' of the second graph and then merge them to have a JSONLD that Google can recognize.

Do you have an alternative method to do what I want ?