Closed gibsonf1 closed 6 years ago
@gibsonf1 these are relative URIs, which are legal in turtle.
Closing, please feel free to raise concerns.
as evidence the grammar has:
№ | label | content | |
---|---|---|---|
[3] | directive | ::= | prefixID | base | sparqlPrefix | sparqlBase |
[4] | prefixID | ::= | '@prefix' PNAME_NS IRIREF '.' |
[18] | IRIREF | ::= | '<' ([^#x00-#x20<>"{}|^`] | UCHAR)* '>' |
and the Term Constructors include:
production | type | procedure |
---|---|---|
IRIREF | IRI | The characters between "<" and ">" are taken, with the numeric escape sequences unescaped, to form the unicode string of the IRI. Relative IRI resolution is performed per Section 6.3. |
@melvincarvalho & @ericprud One problem, the key to relative path resolution per section 6.3 is the base or @base definition of the base URI for relative path resolution, which is missing from the turtle above.
Most importantly, if we were to speculate on what the base is, there are contradictions. Reference the card page: https://gibsonf1.inrupt.net/profile/card
According to the card, storage is at https://gibsonf1.inrupt.net/ (turtle above calls this gib: </> making @base https://gibsonf1.inrupt.net
However, the webid according to the card is https://gibsonf1.inrupt.net/profile/card#me with turtle above defining : as <#> and card as :me - so this would make @base https://gibsonf1.inrupt.net/profile/card so there is clearly a problem in trying to turn this turtle programmatically into valid triples (which I'm trying to do)
The @base or BASE directive defines the Base IRI used to resolve relative IRIs per RFC3986 section 5.1.1, "Base URI Embedded in Content". Section 5.1.2, "Base URI from the Encapsulating Entity" defines how the In-Scope Base IRI may come from an encapsulating document, such as a SOAP envelope with an xml:base directive or a mime multipart document with a Content-Location header. The "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval URI", is the URL from which a particular Turtle document was retrieved. If none of the above specifies the Base URI, the default Base URI (section 5.1.4, "Default Base URI") is used. Each @base or BASE directive sets a new In-Scope Base URI, relative to the previous one.
CL-SOLID> (dex:get "https://gibsonf1.inrupt.net/profile/card")
I think every turtle parser needs to have a way to besides payload also accept base separetaly, in that case IRI which HTTP GET request was made to https://gibsonf1.inrupt.net/profile/card
(where HTTP response doesn't redirect or set a different Location header)
If you use http://www.easyrdf.org/converter with input
url: https://gibsonf1.inrupt.net/profile/card
output format: N-Triples
do you see any invalid statements?
Most importantly, if we were to speculate on what the base is, there are contradictions. Reference the card page: https://gibsonf1.inrupt.net/profile/card According to the card, storage is at https://gibsonf1.inrupt.net/ (turtle above calls this gib: </> making @base https://gibsonf1.inrupt.net However, the webid according to the card is https://gibsonf1.inrupt.net/profile/card#me with turtle above defining : as <#> and card as :me - so this would make @base https://gibsonf1.inrupt.net/profile/card so there is clearly a problem in trying to turn this turtle programmatically into valid triples (which I'm trying to do)
I don't understand why you try to make some assumptions about the base from those prefix definitions. Since turtle representation doesn't include explicit base ("Base URI Embedded in Content") , client application making the HTTP request needs to use "URI from the Retrieval URI".
WIth easyrdf, it's turtle output is this:
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix schema: <http://schema.org/> .
@prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
@prefix ns0: <http://www.w3.org/ns/ldp#> .
@prefix ns1: <http://www.w3.org/ns/pim/space#> .
@prefix ns2: <http://www.w3.org/ns/solid/terms#> .
<https://gibsonf1.inrupt.net/profile/card>
a foaf:PersonalProfileDocument ;
foaf:maker <https://gibsonf1.inrupt.net/profile/card#me> ;
foaf:primaryTopic <https://gibsonf1.inrupt.net/profile/card#me> .
<https://gibsonf1.inrupt.net/profile/card#me>
a schema:Person, foaf:Person ;
vcard:fn "Frederick Gibson" ;
vcard:note "Interesting" ;
vcard:organization-name "graphMetrix Inc." ;
vcard:role "CEO" ;
ns0:inbox <https://gibsonf1.inrupt.net/inbox/> ;
ns1:preferencesFile <https://gibsonf1.inrupt.net/settings/prefs.ttl> ;
ns1:storage <https://gibsonf1.inrupt.net/> ;
ns2:account <https://gibsonf1.inrupt.net/> ;
ns2:privateTypeIndex <https://gibsonf1.inrupt.net/settings/privateTypeIndex.ttl> ;
ns2:publicTypeIndex <https://gibsonf1.inrupt.net/settings/publicTypeIndex.ttl> ;
foaf:name "Frederick Gibson" .
Thanks @elf-pavlik , it looks like I just need to insert a base directive into the turtle output using the request URI before parsing to make this work
In setting up a test account on inrupt.net, I'm getting this turtle back:
CL-SOLID> (dex:get "https://gibsonf1.inrupt.net/profile/card") "@prefix : <#>. @prefix solid: http://www.w3.org/ns/solid/terms#. @prefix pro: <./>. @prefix n0: http://xmlns.com/foaf/0.1/. @prefix schem: http://schema.org/. @prefix n: http://www.w3.org/2006/vcard/ns#. @prefix ldp: http://www.w3.org/ns/ldp#. @prefix inbox: </inbox/>. @prefix sp: http://www.w3.org/ns/pim/space#. @prefix gib: </>.
pro:card a n0:PersonalProfileDocument; n0:maker :me; n0:primaryTopic :me.
:me a schem:Person, n0:Person; n:fn \"Frederick Gibson\"; n:note \"Interesting\"; n:organization-name \"graphMetrix Inc.\"; n:role \"CEO\"; ldp:inbox inbox:; sp:preferencesFile </settings/prefs.ttl>; sp:storage gib:; solid:account gib:; solid:privateTypeIndex </settings/privateTypeIndex.ttl>; solid:publicTypeIndex </settings/publicTypeIndex.ttl>; n0:name \"Frederick Gibson\". "
This turtle is flawed in that the : , pro: , inbox: , and gib: prefixes all do not show the proper IRI - is this just a flaw over at inrupt.com or is this the intention? If I import this turtle, all nodes with those prefixes have the wrong IRIs