Re: Parsing hydra as RDF graph

Firstly, i'm new to all these, so i may have made some wrong assumptions.
At github my name is cr3a7ure, so you can find the apidoc here  (https://
github.com/api-platform/api-platform/issues/142 )

I made the assumption that the apidoc contains most of the information
about the server. So if i could parse it as an RDF graph, i'd have
everything to properly query the server.
I'm wondering, is this true?

Reading the spec (
http://www.hydra-cg.com/spec/latest/core/#documenting-a-web-api) under
ISSUE 7,
it states that:

*Since Hydra uses classes to describe the information expected or returned
> by an operation, it also defines a concept to describe the properties known
> to be supported by a class. The following example illustrates this feature.
> Instead of referencing properties directly, supportedProperty references an
> intermediate data structure, namely instances of the SupportedProperty
> class. This makes it possible to define whether a specific property is
> required or whether it is read-only or write-only depending on the class it
> is associated with.*


 That intermediate data structure has no '@id' field, creating a blank node
like so:


"@id": "http://schema.org/Flight",
"@type": "hydra:Class",
"rdfs:label": "Flight",
"hydra:title": "Flight",
"hydra:description": "An airline flight.",
"hydra:supportedProperty": [
{ /blank_node_start
    "@id": <----------------missing id--------------------------------?
    "@type": "hydra:SupportedProperty",
    "hydra:property": {
        "@id": "#Flight/id", <----------
        "@type": "rdf:Property",
        "rdfs:label": "id",
        "domain": "http://schema.org/Flight",
       "range": "xmls:integer"
    },
    "hydra:title": "id",
    "hydra:required": false,
    "hydra:readable": false,
    "hydra:writable": true
},/blank_node_end

so what we have is BlankNode_23 ---> '@type' ---> "hydra:SupportedProperty"
etc, meaning that it would be difficult to check the hydra properties
[title,required,readable,writable].

As far as blank nodes, @rdflib.js i got this:

Sarven Capadisli @csarven 15:19
@cr3a7ure *You should not merge bnodes with the same name, and you can't
refer to them*. bnodes are local names in a uniquely resolved graph (that's
the scope they are in) and named at the discretion of a serialiser. They
are different than global identifiers which can be referenced (e.g., URI)
and resolved (e.g., HTTP URI). bnodes can be explicitly named but they are
not guaranteed to stick around i.e., once the document is reserialised,
they may be renamed. Lastly, because they are just local names and
ephemeral, bnodes with the same name in two different resources are not
necessarily the same and should not be treated equal.

What do you think about all that?
I'd like to query the rdf graph for those properties instead of parsing the
apidoc as a js object.
I think i made my point clear.

2016-10-01 21:38 GMT+03:00 james anderson <james@dydra.com>:

> good evening;
>
> On 2016-10-01, at 12:26, GoutisD <gts.dmtr@gmail.com> wrote:
>
> Greetings list,
>
> i'm using the https://api-platform.com/ (which is great btw) server side
> and the rdflib.js (https://github.com/linkeddata/rdflib.js
> <https://github.com/linkeddata/rdflib..js>) client side playing around
> with rdf graphs.
>
> When i'm parsing the jsonld as RDF graph i get a lot of blank nodes. Which
> may not seem as a problem at first, but the same blank nodes, are assigned
> a new id every time they are mentioned.
>
>
> that is a quite remarkable statement.
> could you describe what is happening in more detail?
>
> I'm not sure if we can refer to a blank node the same way we can with a
> named one.
>
> Have a look at the example here https://github.com/api-
> platform/api-platform/issues/144
>
> PS: I'll check rdflib.js also
>
>
>
>
> ---
> james anderson | james@dydra.com | http://dydra.com
>
>
>
>
>
>