Open jgmikael opened 4 months ago
Hell @jgmikael, please could you see the endpoint here https://virtuoso.ecdp.tech.ec.europa.eu/ where we publish the data (KG) with different use cases:
An Operational Point here https://virtuoso.ecdp.tech.ec.europa.eu/describe/?url=http%3A%2F%2Fdata.europa.eu%2F949%2FfunctionalInfrastructure%2FoperationalPoints%2FEEKIISA
I support @jgmikael . @gatemezing:
Now let's see what happens with one instance URL
curl -L -Hacept:text/turtle http://data.europa.eu/949/functionalInfrastructure/operationalPoints/BG83010
But it returns a webpage that starts like this:
OpenLink Software Facets (new session) Description Metadata Settings About: http://data.europa.eu/949/functionalInfrastructure/operationalPoints/BG83010 Goto Sponge NotDistinct Permalink
LINK
headers and links to download semantic formats at the bottom, but all of them return empty. Eg the Turtle link looks like thsi:
curl -L -Hacept:application/rdf+xml http://data.europa.eu/949/functionalInfrastructure/operationalPoints/BG83010
curl -L -Hacept:application/ld+json http://data.europa.eu/949/functionalInfrastructure/operationalPoints/BG83010
but it returns an error:
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>
Thanks for your support @VladimirAlexiev :-)
Would be interesting to know whether the missing resolvability & content negotiation is an issue for anyone else > if the modeling tools where these vocabularies are supposedly used don't support "online usage" then this is not an issue at all...
Hello @VladimirAlexiev, You did your test probably when the server was down. Yes, we had some issues last week with server stability. ERA as an EU agency receives from PO a unique namespace for KG publication, including ontology - We do our best to make dereferenceable data - Of course, there can be limitations (do you remember the old debate on whether using # or / for namespace?). See this few list of ontologies from EU Agency in LOV)%0A+++++++%0A+++++%0A%09%7D%7D+ORDER+BY+%3FvocabPrefix).
So, coming back to your example URIs.
[ ] curl -L -H "Accept:text/turtle" http://data.europa.eu/949/functionalInfrastructure/operationalPoints/BG83010
- gives empty Turtle (because it is the canonical URI )
[ ] If you want the corresponding OP, you have it here curl -LH "Accept:text/turtle" http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246
[ ] same for RDF/XML here with output curl -LH "Accept:application/rdf+xml" http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246
[ ] I do see empty result for JSON-LD curl -LH "Accept:application/ld+json" http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246
We will try to figure out the issues for those empty results (case of JSON-LD).
@gatemezing I apologize, my curl examples have a misspelling: acept
instead of accept
, that's why they return HTML.
Then I have some questions and suggestions for improvement:
era:
but can also include instance prefixes like era-operationalPoints: era-netElements: era-netRelations:
nsN
, and the prefixes are intermixed with the data, eg:@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ns1: <http://data.europa.eu/949/> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> rdf:type ns1:OperationalPoint .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> rdfs:label "AYTOS" .
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> geo:location <http://data.europa.eu/949/locations/%2B27.2463/42.6947> .
@prefix ns4: <http://publications.europa.eu/resource/authority/country/> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> ns1:inCountry ns4:BGR ;
ns1:opName "AYTOS" ;
ns1:opType <http://data.europa.eu/949/concepts/op-types/rinf/20> ;
ns1:uopid "BG83010" .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> ns1:validityEndDate "2050-12-31"^^xsd:date ;
ns1:validityStartDate "2017-04-20"^^xsd:date .
@prefix ns6: <http://data.europa.eu/949/functionalInfrastructure/operationalPoints/> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> ns1:canonicalURI ns6:BG83010 ;
ns1:hashSource "BG/BG83010/20/2017-04-20_2050-12-31" .
@prefix ns7: <http://data.europa.eu/949/topology/netElements/> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> ns1:hasAbstraction ns7:BG83010 .
@prefix ns8: <http://data.europa.eu/949/functionalInfrastructure/tracks/> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> ns1:track ns8:a66eda088b9616313a597578679f2113154edfa8 ,
ns8:a8005a6411ed54984a132bf15a78f0e6993e502e ,
<http://data.europa.eu/949/functionalInfrastructure/tracks/747981fbe3e4c5fe8df510658dce4740978ed31c> ,
<http://data.europa.eu/949/functionalInfrastructure/tracks/6c6e139ef682406101e51050dddc16a27640294d> ;
ns1:notApplicable ns1:opTypeGaugeChangeover .
@prefix ns9: <http://data.europa.eu/949/functionalInfrastructure/sidings/> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> ns1:siding ns9:ad97e2bbbecc430515251d4de0b7da5bfa347895 .
@prefix ogcgs: <http://www.opengis.net/ont/geosparql#> .
<http://data.europa.eu/949/functionalInfrastructure/operationalPoints/3894cc408fa8ecffa427789c31ff0206f01c9246> ogcgs:hasGeometry <http://data.europa.eu/949/locations/%2B27.2463/42.6947> ;
ns1:lineReference <http://data.europa.eu/949/functionalInfrastructure/lineReferences/8_258.865> ;
ns1:tafTAPCode "BG83010" .
Given @prefix ns8:
I have no explanation why Virtuoso
ns8:a8005a6411ed54984a132bf15a78f0e6993e502e
<http://data.europa.eu/949/functionalInfrastructure/tracks/747981fbe3e4c5fe8df510658dce4740978ed31c>
Thank you @VladimirAlexiev - I ping @ocorcho to give his opinion on this matter. Regarding Virtuoso, we could certainly check to define the preferred prefixes so that it reused the same CURIE during the export.
"Do you guarantee that the URL with the long "guid" is permanent and will never change?" This cannot be guaranteed for the long guid, since this is the result of a generating a URI with a hash in the end that is created from the opID and the validity dates in which that data is applicable. When that data is not any more available, then the URI will disappear. This is by design of the validity dates concept for OPs, SoLs, tracks, etc.
"The canonical shouldn't return empty because it has incoming links" You are right on that. This will need to be explored since it seems to be a Virtuoso configuration issue, as the corresponding HTML page from Virtuoso has the incoming links indeed. @gatemezing you can add this as a ticket.
"Namespaces" In principle, this does not affect any machine (only humans) that reads the data. But it is a nice-to-have to generate that Turtle more homogeneously when it needs to be shown for some purpose. @gatemezing you can add this as a ticket with minor priority.
Re "namespace" - @ocorcho yes, there is ticket https://citnet.tech.ec.europa.eu/CITnet/jira/browse/LD4RAIL-1170 with the comment
"The canonical shouldn't return empty because it has incoming links" You are right on that. This will need to be explored since it seems to be a Virtuoso configuration issue, as the corresponding HTML page from Virtuoso has the incoming links indeed.
See https://citnet.tech.ec.europa.eu/CITnet/jira/browse/LD4RAIL-1178 (only for those who have access to the Gitlab)
Hi,
would it be possible to publish the ERA Vocabulary as "real" Linked Data, by which I mean that the contents could be accessible and linkable online, not only through offline use?
The changes would include:
A similar approach has already been introduced in the following namespaces: https://vocabulary.uncefact.org/ http://data.europa.eu/snb/model/elm/ http://data.europa.eu/m8g/
What can be accomplished by this? Well, with the proper toolset, like the Finnish National Interoperability Platform's "Data Vocabularies" tool (https://tietomallit.suomi.fi/ (language:EN) the linked external vocabulary can be reused directly either in other vocabularies or directly in application profiles (SHACL Shapes). Huge advantage compared to cumbersome manual work with different tools needing advanced expertise in the area of W3C Semantic Web technologies.