Abuse of describedby relation in link header #197

Closed
cygri opened this Issue Nov 13, 2012 · 46 comments

Comments

Projects
None yet
6 participants
@cygri

cygri commented Nov 13, 2012

Section 7.4 Referencing Contexts from JSON Documents says that an HTTP header with relation describedby can be used to associate an external context with a JSON document.

I'm concerned that this is an abuse of the describedby header.

The semantics of describedby relation type, as defined by POWDER and registered with IANA, is to link to a POWDER document that describes the subject resource, in other words, provides metadata about it.

Thus, if there's a describedby link from a JSON document to a JSON-LD document, the correct interpretation to me seems to be that the latter is a POWDER document serialized in JSON-LD that provides metadata about the JSON document. Nothing in the relationship type registration or in the POWDER spec suggests that it can be interpreted as an association of a JSON-LD context with the JSON document that allows processing the JSON document as JSON-LD.

It seems to me that JSON-LD should define its own relationship type with the precise semantics as described in Section 7.4, or else drop the mechanism described in 7.4.

@tidoust

This comment has been minimized.

Show comment
Hide comment
@tidoust

tidoust Nov 13, 2012

Contributor

While the section in POWDER seems to imply that describedBy is for POWDER, the actual Link Relationship submitted to IANA defined in Appendix D: describedby Link Relationship is actually explicit that there are no constraints on formats:

The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.
http://www.w3.org/TR/powder-dr/#appD

That seems in line with the use made in JSON-LD.

At a minimum, JSON-LD should reference the definition of describedBy in POWDER.

Contributor

tidoust commented Nov 13, 2012

While the section in POWDER seems to imply that describedBy is for POWDER, the actual Link Relationship submitted to IANA defined in Appendix D: describedby Link Relationship is actually explicit that there are no constraints on formats:

The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.
http://www.w3.org/TR/powder-dr/#appD

That seems in line with the use made in JSON-LD.

At a minimum, JSON-LD should reference the definition of describedBy in POWDER.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 13, 2012

Member

I agree with François on this. Would using a link relation of "edit" be an abuse at that is defined by Atom? I don't think so.

I don’t see a requirement to reference POWDER since IANA maintains the link relation registry [1]. They will update the registry with a pointer to the JSON-LD spec (if accepted) and that's it.

[1] http://www.iana.org/assignments/link-relations/link-relations.xml

Member

lanthaler commented Nov 13, 2012

I agree with François on this. Would using a link relation of "edit" be an abuse at that is defined by Atom? I don't think so.

I don’t see a requirement to reference POWDER since IANA maintains the link relation registry [1]. They will update the registry with a pointer to the JSON-LD spec (if accepted) and that's it.

[1] http://www.iana.org/assignments/link-relations/link-relations.xml

@cygri

This comment has been minimized.

Show comment
Hide comment
@cygri

cygri Nov 14, 2012

The abuse stems not from the fast that the target isn't a POWDER resource. The abuse stems from the fact that the target isn't a description in JSON-LD of the source.

A @context is not a description of a JSON document. It is a processing instruction that says how a JSON document can be processed as JSON-LD.

An appropriate use of rel="describedy" type="application/json-ld" would be a real JSON-LD document that describes the source.

The current design precludes the use of actual JSON-LD documents with rel="describedby".

cygri commented Nov 14, 2012

The abuse stems not from the fast that the target isn't a POWDER resource. The abuse stems from the fact that the target isn't a description in JSON-LD of the source.

A @context is not a description of a JSON document. It is a processing instruction that says how a JSON document can be processed as JSON-LD.

An appropriate use of rel="describedy" type="application/json-ld" would be a real JSON-LD document that describes the source.

The current design precludes the use of actual JSON-LD documents with rel="describedby".

@niklasl

This comment has been minimized.

Show comment
Hide comment
@niklasl

niklasl Nov 14, 2012

Member

I agree, the semantics seem quite different. What's needed is something like rel=profile or rel=transformation (see GRDDL: http://www.w3.org/2003/g/data-view). None of those are registered IANA relations though, so we need a full URI. Either one of those, or for a new "context" property, unless someone finds anything more appropriate (I'm not particularly fond of the microformats list of existing rel values, but we might shop around there as well I presume.)

(In a convergent world, where JSON-LD contexts could be used with microdata, what would be the appropriate link relation to such a context?)

Member

niklasl commented Nov 14, 2012

I agree, the semantics seem quite different. What's needed is something like rel=profile or rel=transformation (see GRDDL: http://www.w3.org/2003/g/data-view). None of those are registered IANA relations though, so we need a full URI. Either one of those, or for a new "context" property, unless someone finds anything more appropriate (I'm not particularly fond of the microformats list of existing rel values, but we might shop around there as well I presume.)

(In a convergent world, where JSON-LD contexts could be used with microdata, what would be the appropriate link relation to such a context?)

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 14, 2012

Member

Sorry, I still disagree. IANA (which is the authoritative source here) defines the semantics of describedby as follows:

Refers to a resource providing information about the link's context.

Maybe I'm missing something, but aren't we using it for exactly that reason? We provide information about a JSON document's context which allows a JSON-LD processor to interpret it as Linked Data.

Member

lanthaler commented Nov 14, 2012

Sorry, I still disagree. IANA (which is the authoritative source here) defines the semantics of describedby as follows:

Refers to a resource providing information about the link's context.

Maybe I'm missing something, but aren't we using it for exactly that reason? We provide information about a JSON document's context which allows a JSON-LD processor to interpret it as Linked Data.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 14, 2012

Thanks to François for alerting me to this thread.

On the semantics of describedby, I can ally all fears. The IANA definition is correct - if A is describedby B there is no inference that B is a POWDER doc. The error in the Recommendation is recorded at http://www.w3.org/2007/powder/powder-errata#describedby (an error that has caused me more pain than I can recount, not least trying to work out how the heck I can update the docs within W3C policy on editing stuff once it's in /TR space but that's a side issue).

However, from there on it gets a little less clear.

I have sympathy with Richard's view that @context is a processing document - a set of instructions cf. a description. However, I also have sympathy with the view that a document that tells me how to interpret another one is, in at least some sense, a description of it. A translation of this text into French would in at least some sense describe the content to a monoglot French speaker. A glossary can be seen as providing descriptions of terms - OK, we'd say definitions of terms, not descriptions but it's close.

Yes, transform is probably a better word than describedby in this context, but I go back to the definition:

"The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource."

The constraint comes from the MIME type of A and B. The spec could make explicit that:

If A is application/json and B is application/json-ld then

A rel="describedby" B implies that B is a description of how to process A into JSON-LD

HTH

Phil.

ghost commented Nov 14, 2012

Thanks to François for alerting me to this thread.

On the semantics of describedby, I can ally all fears. The IANA definition is correct - if A is describedby B there is no inference that B is a POWDER doc. The error in the Recommendation is recorded at http://www.w3.org/2007/powder/powder-errata#describedby (an error that has caused me more pain than I can recount, not least trying to work out how the heck I can update the docs within W3C policy on editing stuff once it's in /TR space but that's a side issue).

However, from there on it gets a little less clear.

I have sympathy with Richard's view that @context is a processing document - a set of instructions cf. a description. However, I also have sympathy with the view that a document that tells me how to interpret another one is, in at least some sense, a description of it. A translation of this text into French would in at least some sense describe the content to a monoglot French speaker. A glossary can be seen as providing descriptions of terms - OK, we'd say definitions of terms, not descriptions but it's close.

Yes, transform is probably a better word than describedby in this context, but I go back to the definition:

"The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource."

The constraint comes from the MIME type of A and B. The spec could make explicit that:

If A is application/json and B is application/json-ld then

A rel="describedby" B implies that B is a description of how to process A into JSON-LD

HTH

Phil.

@cygri

This comment has been minimized.

Show comment
Hide comment
@cygri

cygri Nov 14, 2012

@lanthaler I doubt that the word “context” as used in the describedby registration has anything to do with the thing called “context” in JSON-LD.

@philarcher Your proposal precludes the use of JSON-LD as a format to actually describe JSON documents.

cygri commented Nov 14, 2012

@lanthaler I doubt that the word “context” as used in the describedby registration has anything to do with the thing called “context” in JSON-LD.

@philarcher Your proposal precludes the use of JSON-LD as a format to actually describe JSON documents.

@tidoust

This comment has been minimized.

Show comment
Hide comment
@tidoust

tidoust Nov 14, 2012

Contributor

OK, I get it this time and agree: we'll want to use JSON-LD as a description format to make statements that describe other JSON or JSON-LD documents and we'd need to use the describedBy relation to do that.

I also agree with Niklas that GRDDL's transformation matches our use case:
http://www.w3.org/TR/grddl/#grddlvocab

Contributor

tidoust commented Nov 14, 2012

OK, I get it this time and agree: we'll want to use JSON-LD as a description format to make statements that describe other JSON or JSON-LD documents and we'd need to use the describedBy relation to do that.

I also agree with Niklas that GRDDL's transformation matches our use case:
http://www.w3.org/TR/grddl/#grddlvocab

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 14, 2012

Member

@lanthaler I doubt that the word “context” as used in the describedby registration has anything to do with the thing called context” in JSON-LD.

Why not? Doesn't a JSON-LD context provide contextual information which allows programs understanding JSON, JSON-LD and the describedby link relation used with those two media types to interpret the resource that linked to that contextual information?

@philarcher Your proposal precludes the use of JSON-LD as a format to actually describe JSON documents.

I don't think so.. that would just be a different representation of the same data and "alternate" would be the right link relation in that case (IMO at least).

Member

lanthaler commented Nov 14, 2012

@lanthaler I doubt that the word “context” as used in the describedby registration has anything to do with the thing called context” in JSON-LD.

Why not? Doesn't a JSON-LD context provide contextual information which allows programs understanding JSON, JSON-LD and the describedby link relation used with those two media types to interpret the resource that linked to that contextual information?

@philarcher Your proposal precludes the use of JSON-LD as a format to actually describe JSON documents.

I don't think so.. that would just be a different representation of the same data and "alternate" would be the right link relation in that case (IMO at least).

@cygri

This comment has been minimized.

Show comment
Hide comment
@cygri

cygri Nov 14, 2012

@lanthaler

  1. Because “context”, according to the dictionary, means “surrounding circumstances”, “interrelated conditions”. That is consistent with how the IANA registration uses the term AFAICT, and it's not consistent with how JSON-LD uses it. Information about how to interpret something else isn't “contextual information” about that thing.
  2. I talked about using a JSON-LD document to describe a JSON document. That's not a different representation of the same data. Do I need to explain to you the difference between a thing and a description of the thing?

cygri commented Nov 14, 2012

@lanthaler

  1. Because “context”, according to the dictionary, means “surrounding circumstances”, “interrelated conditions”. That is consistent with how the IANA registration uses the term AFAICT, and it's not consistent with how JSON-LD uses it. Information about how to interpret something else isn't “contextual information” about that thing.
  2. I talked about using a JSON-LD document to describe a JSON document. That's not a different representation of the same data. Do I need to explain to you the difference between a thing and a description of the thing?
@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 15, 2012

Member
  1. Because “context”, according to the dictionary, means “surrounding circumstances”, “interrelated conditions”. That is consistent with how the IANA registration uses the term AFAICT, and it's not consistent with how JSON-LD uses it. Information about how to interpret something else isn't “contextual information” about that thing.

Well, in my opinion it is:

  • Context: "the parts of a written or spoken statement that precede or follow a specific word or passage, usually influencing its meaning or effect" dictionary.com
  • "context, those parts of a text preceding and following any particular passage, giving it a meaning fuller or more identifiable than if it were read in isolation" answers.com
  • Context: "the parts of a discourse that surround a word or passage and can throw light on its meaning" Merriam Webbster
  • Context: "The part of a text or statement that surrounds a particular word or passage and determines its meaning." The free dictionary

2.I talked about using a JSON-LD document to describe a JSON document. That's not a different representation of the same data. Do I need to explain to you the difference between a thing and a description of the thing?

No. Please don't let us go down that path..

Member

lanthaler commented Nov 15, 2012

  1. Because “context”, according to the dictionary, means “surrounding circumstances”, “interrelated conditions”. That is consistent with how the IANA registration uses the term AFAICT, and it's not consistent with how JSON-LD uses it. Information about how to interpret something else isn't “contextual information” about that thing.

Well, in my opinion it is:

  • Context: "the parts of a written or spoken statement that precede or follow a specific word or passage, usually influencing its meaning or effect" dictionary.com
  • "context, those parts of a text preceding and following any particular passage, giving it a meaning fuller or more identifiable than if it were read in isolation" answers.com
  • Context: "the parts of a discourse that surround a word or passage and can throw light on its meaning" Merriam Webbster
  • Context: "The part of a text or statement that surrounds a particular word or passage and determines its meaning." The free dictionary

2.I talked about using a JSON-LD document to describe a JSON document. That's not a different representation of the same data. Do I need to explain to you the difference between a thing and a description of the thing?

No. Please don't let us go down that path..

@cygri

This comment has been minimized.

Show comment
Hide comment
@cygri

cygri Nov 15, 2012

It's doubtful that this is the sense that the IANA registration intends. Also, how does any of those definitions apply to JSON-LD?

cygri commented Nov 15, 2012

It's doubtful that this is the sense that the IANA registration intends. Also, how does any of those definitions apply to JSON-LD?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 15, 2012

This really isn't my argument but fwiw I agree that GRDDL's @rel type of transformation is a better fit than describedby. Getting it into the HTTP Link Registry is not hard (http://tools.ietf.org/html/rfc5988#section-6.2) especially as transformation is defined in a W3C Rec already.

However... that raises a number of issues, firstly and most easily, although the GRDDL Rec does define @rel transformation, it doesn't of course magically edit the XHTML spec (http://www.w3.org/TR/xhtml-modularization/abstraction.html#s_common_types) nor does it make it into HTML5 http://dev.w3.org/html5/spec-preview/links.html#linkTypes but if you include it in the JSON-LD spec and get Mark Nottingham to include it in the registry, then the job might be done.

But there's more... you then run into exactly the problem that kicked off this discussion. The range of transformation is Transformation, defined as "an InformationResource that specifies a transformation from a set of XML documents to RDF graphs..." Which basically gives you a domain of XML and a range of RDF. The reason describedby gets traction (despite the erratum) is that it does no such thing. describedby was actually defined over a very pleasant lunch I had with MNott at Cambridge Circus in London. His key message was to make sure that the relationship did not have any domain and range and to let the MIME types do their job. That's why the (proper) definition of describedby says that given the assertion: A describedby B, the only inference is that B describes A. It tells you nothing about what format A and B are in.

Therefore, using GRDDL's transformation property could be problematic and I come back to Richard's original thought that actually, a new term may need to be minted. Thrashing around my native speaker skull for an alternative I wonder whether either 'augment' or 'processable' might do what is needed? So:

A augment B

would say that B can augment (i.e. add to/enrich) A

alternatively

A processable B

says only that B can be used to process A.

The problem with augment is that it might be seen as pejorative (i.e. people who think JSON is all you ever need for everything will balk at the idea that JSON-LD is in some way augmented). Although I think it's a better term than processable since why would you ever want to link to anything that wasn't? ;-)

The problem ever here is that actually there are 3 elements: the input file A (JSON), the context file B (also JSON) and the output JSON-LD... and linked relationships don't really cover that. Even so, I think the fact that B augments A is what we're looking at here and since the output is also JSON, it should be OK?? Convention and usage are powerful things...

ghost commented Nov 15, 2012

This really isn't my argument but fwiw I agree that GRDDL's @rel type of transformation is a better fit than describedby. Getting it into the HTTP Link Registry is not hard (http://tools.ietf.org/html/rfc5988#section-6.2) especially as transformation is defined in a W3C Rec already.

However... that raises a number of issues, firstly and most easily, although the GRDDL Rec does define @rel transformation, it doesn't of course magically edit the XHTML spec (http://www.w3.org/TR/xhtml-modularization/abstraction.html#s_common_types) nor does it make it into HTML5 http://dev.w3.org/html5/spec-preview/links.html#linkTypes but if you include it in the JSON-LD spec and get Mark Nottingham to include it in the registry, then the job might be done.

But there's more... you then run into exactly the problem that kicked off this discussion. The range of transformation is Transformation, defined as "an InformationResource that specifies a transformation from a set of XML documents to RDF graphs..." Which basically gives you a domain of XML and a range of RDF. The reason describedby gets traction (despite the erratum) is that it does no such thing. describedby was actually defined over a very pleasant lunch I had with MNott at Cambridge Circus in London. His key message was to make sure that the relationship did not have any domain and range and to let the MIME types do their job. That's why the (proper) definition of describedby says that given the assertion: A describedby B, the only inference is that B describes A. It tells you nothing about what format A and B are in.

Therefore, using GRDDL's transformation property could be problematic and I come back to Richard's original thought that actually, a new term may need to be minted. Thrashing around my native speaker skull for an alternative I wonder whether either 'augment' or 'processable' might do what is needed? So:

A augment B

would say that B can augment (i.e. add to/enrich) A

alternatively

A processable B

says only that B can be used to process A.

The problem with augment is that it might be seen as pejorative (i.e. people who think JSON is all you ever need for everything will balk at the idea that JSON-LD is in some way augmented). Although I think it's a better term than processable since why would you ever want to link to anything that wasn't? ;-)

The problem ever here is that actually there are 3 elements: the input file A (JSON), the context file B (also JSON) and the output JSON-LD... and linked relationships don't really cover that. Even so, I think the fact that B augments A is what we're looking at here and since the output is also JSON, it should be OK?? Convention and usage are powerful things...

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 15, 2012

Member

Sorry but I don't think this discussion here leads to anything. I therefore wrote a mail to IETF's link-relations mailing list to ask for their opinion. In the end they are the maintainers of the registry and consequently the responsible authority.

Member

lanthaler commented Nov 15, 2012

Sorry but I don't think this discussion here leads to anything. I therefore wrote a mail to IETF's link-relations mailing list to ask for their opinion. In the end they are the maintainers of the registry and consequently the responsible authority.

@cygri

This comment has been minimized.

Show comment
Hide comment
@cygri

cygri Nov 15, 2012

@lanthaler Okay I'll spell this out once more for you.

Let's say there's a nice JSON file at http://alice.example.com/addresses.json. It's a dump from Alice's address book app in a JSON format specific to that app.

Now, Alice also publishes some RDF metadata that describes the stuff on her website. That's published in Turtle at http://alice.example.com/meta.ttl and contains this bit:

<addresses.json> a foaf:Document;
    dc:title "My address book in FooAddress dump format";
    dc:modified "2012-11-15T12:34:56"^^xsd:dateTime.

Now, Alice would like that metadata to be discoverable from the JSON file itself. That's what the Link HTTP header is for, right? So she configures the server to add that header. Looking for an appropriate link relationship, she finds describedby which seems to be perfectly appropriate:

Link: <meta.ttl>; rel="describedby" type="text/turtle";

Great! Now, any processor that understands the describedby relationship and Turtle can find the metadata!

A bit later, Alice hears about this new thing called JSON-LD. She looks at it and decides that it's much better than Turtle. She does away with meta.ttl and publishes meta.jsonld instead, with appropriate media type and all. It looks something like this:

{
    "@context": {
        "foaf":"http://xmlns.com/foaf/0.1/",
        "dc":"http://purl.org/dc/terms/",
        "xsd":"http://www.w3.org/2001/XMLSchema#",
        "dc:modified":{"@type":"xsd:dateTime"}
    },
    "@id": "addresses.json",
    "@type": "foaf:Document",
    "dc:title": "My address book in FooAddress dump format",
    "dc:modified": "2012-11-15T12:34:56"
}

Of course she also changes the link header:

Link: <meta.jsonld>; rel="describedby" type="application/ld+json";

Great! Now, any processor that understands the describedby relationship and JSON-LD can find the metadata!

Or can it? No, because according to the JSON-LD spec, a JSON-LD processor has to interpret this header as copying the @context from Alice's metadata document into the address book app's JSON dump! So, instead of having metadata associated with the JSON dump as Alice intended, she now has a JSON-LD processor that produces garbage by interpreting her address book dump as JSON-LD with a context not intended for it.

The problem is caused by imposing a definition of the describedby header that is much narrower than what's written in the IANA registration. Thereby preventing reasonable uses of describedby that lie within the scope of the IANA registration, but outside of the narrow interpretation demanded by the JSON-LD draft.

The fix is one of those:

  • Use a different rel value
  • Use different media types for JSON-LD documents and stand-alone JSON-LD contexts
  • Use not @context to signify the JSON-LD context to be used, but a different key (@ThisIsAnExternallyReferenceableContext), and state that if it is absent, the usual interpretation of describedby applies
  • Drop section 7.4

Update: Edited the conclusion paragraph and list of fixes

cygri commented Nov 15, 2012

@lanthaler Okay I'll spell this out once more for you.

Let's say there's a nice JSON file at http://alice.example.com/addresses.json. It's a dump from Alice's address book app in a JSON format specific to that app.

Now, Alice also publishes some RDF metadata that describes the stuff on her website. That's published in Turtle at http://alice.example.com/meta.ttl and contains this bit:

<addresses.json> a foaf:Document;
    dc:title "My address book in FooAddress dump format";
    dc:modified "2012-11-15T12:34:56"^^xsd:dateTime.

Now, Alice would like that metadata to be discoverable from the JSON file itself. That's what the Link HTTP header is for, right? So she configures the server to add that header. Looking for an appropriate link relationship, she finds describedby which seems to be perfectly appropriate:

Link: <meta.ttl>; rel="describedby" type="text/turtle";

Great! Now, any processor that understands the describedby relationship and Turtle can find the metadata!

A bit later, Alice hears about this new thing called JSON-LD. She looks at it and decides that it's much better than Turtle. She does away with meta.ttl and publishes meta.jsonld instead, with appropriate media type and all. It looks something like this:

{
    "@context": {
        "foaf":"http://xmlns.com/foaf/0.1/",
        "dc":"http://purl.org/dc/terms/",
        "xsd":"http://www.w3.org/2001/XMLSchema#",
        "dc:modified":{"@type":"xsd:dateTime"}
    },
    "@id": "addresses.json",
    "@type": "foaf:Document",
    "dc:title": "My address book in FooAddress dump format",
    "dc:modified": "2012-11-15T12:34:56"
}

Of course she also changes the link header:

Link: <meta.jsonld>; rel="describedby" type="application/ld+json";

Great! Now, any processor that understands the describedby relationship and JSON-LD can find the metadata!

Or can it? No, because according to the JSON-LD spec, a JSON-LD processor has to interpret this header as copying the @context from Alice's metadata document into the address book app's JSON dump! So, instead of having metadata associated with the JSON dump as Alice intended, she now has a JSON-LD processor that produces garbage by interpreting her address book dump as JSON-LD with a context not intended for it.

The problem is caused by imposing a definition of the describedby header that is much narrower than what's written in the IANA registration. Thereby preventing reasonable uses of describedby that lie within the scope of the IANA registration, but outside of the narrow interpretation demanded by the JSON-LD draft.

The fix is one of those:

  • Use a different rel value
  • Use different media types for JSON-LD documents and stand-alone JSON-LD contexts
  • Use not @context to signify the JSON-LD context to be used, but a different key (@ThisIsAnExternallyReferenceableContext), and state that if it is absent, the usual interpretation of describedby applies
  • Drop section 7.4

Update: Edited the conclusion paragraph and list of fixes

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 15, 2012

Member

Richard, I understand your point but in the end they are two different use cases. IMO the describedby link relation is completely appropriate for both.

We say (perhaps not clearly enough) that if you link from a JSON to a JSON-LD document via a describedby link relation, a JSON-LD processor can take the @context of the referenced JSON-LD document to interpret that JSON document.

I agree that our definition is much narrower than IANA's definition but that doesn't automatically invalidate it. IANA's definition is independent of specific media types and software products. We just specifiy how it should be used by a JSON-LD processor for a JSON document linking to a JSON-LD document.

What rel value would you suggest instead?

Member

lanthaler commented Nov 15, 2012

Richard, I understand your point but in the end they are two different use cases. IMO the describedby link relation is completely appropriate for both.

We say (perhaps not clearly enough) that if you link from a JSON to a JSON-LD document via a describedby link relation, a JSON-LD processor can take the @context of the referenced JSON-LD document to interpret that JSON document.

I agree that our definition is much narrower than IANA's definition but that doesn't automatically invalidate it. IANA's definition is independent of specific media types and software products. We just specifiy how it should be used by a JSON-LD processor for a JSON document linking to a JSON-LD document.

What rel value would you suggest instead?

@cygri

This comment has been minimized.

Show comment
Hide comment
@cygri

cygri Nov 15, 2012

They are indeed two different use cases. The problem is that the draft as written prevents a legitimate use case. As written, describedby cannot be used with JSON-LD for the purpose that describedby and JSON-LD were made for—associating metadata with a resource, and expressing data.

I have not researched other rel values, so don't have an opinion on what else to use.

cygri commented Nov 15, 2012

They are indeed two different use cases. The problem is that the draft as written prevents a legitimate use case. As written, describedby cannot be used with JSON-LD for the purpose that describedby and JSON-LD were made for—associating metadata with a resource, and expressing data.

I have not researched other rel values, so don't have an opinion on what else to use.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 15, 2012

Member

It cannot be used with a JSON-LD processor for that purpose as a JSON-LD processor would interpret it that way. Maybe all we need to do is to make it clearer that this is how a JSON-LD processor uses such a link!?

Member

lanthaler commented Nov 15, 2012

It cannot be used with a JSON-LD processor for that purpose as a JSON-LD processor would interpret it that way. Maybe all we need to do is to make it clearer that this is how a JSON-LD processor uses such a link!?

@cygri

This comment has been minimized.

Show comment
Hide comment
@cygri

cygri Nov 15, 2012

No, because it permanently precludes a legitimate use case with no way of fixing it later once the current draft design gets deployed.

We're 18 comments in, and you still haven't stated a single reason that justifies the questionable design choice, except insisting that no problem exists.

I think I've done an honest effort here. I'll raise this again as a Last Call comment, and am unlikely to stand aside for a no-change proposal.

In the meantime, consider the easiest way of resolving this:

PROPOSAL: Do not include a HTTP header based context discovery mechanism in JSON-LD 1.0

cygri commented Nov 15, 2012

No, because it permanently precludes a legitimate use case with no way of fixing it later once the current draft design gets deployed.

We're 18 comments in, and you still haven't stated a single reason that justifies the questionable design choice, except insisting that no problem exists.

I think I've done an honest effort here. I'll raise this again as a Last Call comment, and am unlikely to stand aside for a no-change proposal.

In the meantime, consider the easiest way of resolving this:

PROPOSAL: Do not include a HTTP header based context discovery mechanism in JSON-LD 1.0

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 15, 2012

That can't be right, Richard. That is, your proposal not to include HTTP Link because the WG can't agree on a @rel type.

Separate train of thought but we (the W3C Team) are looking at possible support for a new WG to look at Data on the Web. JSON and JSON-LD should, I hope, be very relevant. A hot topic though is data discovery. DCAT is fine for describing datasets but how can you programmatically find them? I know this is something you and Michael have looked at in detail. Anyway... my point in mentioning it is that HTTP Link is a possible part of the solution (as well as /.well-known/ which I hate with a passion for its anti-Web horribleness but accept it's not going to go away, just like accessURL Grrr...)

Here we have a real case where we have one thing that has a clear relation to another. Moreover, the first thing doesn't have an easy declarative way of saying "look over there for stuff you might want too" within it. Therefore HTTP Link is, I think, very much in play as a possible solution.

Please don't throw the baby out with the bath water. Put it to a WG vote and see what happens. If I were in the WG, I would vote for the creation of a new @rel type and possibly a new MIME type for a context file. It's not that much work to put in the spec although of course that's the easy part. It's the software to recognise it that's important.

That's what's needed and I'm struggling to understand lanthaler's continued support for describedby when, AFAICS, he's a lone voice. I've been there, done that, and moved on (see accessURL above!). And hey, I defined describedby so I'd like to see it used everywhere - but only where it's the right thing to do which I don't think this is. I can see how you'd force its use, but no overwhelming reason to do so.

A bit of process... a WG member can make a formal objection (http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews) which triggers a Director review. What would happen is that the WG would vote to go to the next stage with the text written in line with the majority view but the Director would then consider the formal objection (raised presumably by the losing party) and take a decision.

Why do I care? Nothing to do with POWDER I assure you. It's because HTTP Link is a good feature of the Web that should never have been removed. It should just be a normal everyday part of any user agent and right now it isn't. I'd like that to change. It would help JSON-LD and many other things too. It keeps coming up and people say "oh well, I'm sure how widely implemented that is..." and go off. Make it useful, use it properly, and people will implement it.

ghost commented Nov 15, 2012

That can't be right, Richard. That is, your proposal not to include HTTP Link because the WG can't agree on a @rel type.

Separate train of thought but we (the W3C Team) are looking at possible support for a new WG to look at Data on the Web. JSON and JSON-LD should, I hope, be very relevant. A hot topic though is data discovery. DCAT is fine for describing datasets but how can you programmatically find them? I know this is something you and Michael have looked at in detail. Anyway... my point in mentioning it is that HTTP Link is a possible part of the solution (as well as /.well-known/ which I hate with a passion for its anti-Web horribleness but accept it's not going to go away, just like accessURL Grrr...)

Here we have a real case where we have one thing that has a clear relation to another. Moreover, the first thing doesn't have an easy declarative way of saying "look over there for stuff you might want too" within it. Therefore HTTP Link is, I think, very much in play as a possible solution.

Please don't throw the baby out with the bath water. Put it to a WG vote and see what happens. If I were in the WG, I would vote for the creation of a new @rel type and possibly a new MIME type for a context file. It's not that much work to put in the spec although of course that's the easy part. It's the software to recognise it that's important.

That's what's needed and I'm struggling to understand lanthaler's continued support for describedby when, AFAICS, he's a lone voice. I've been there, done that, and moved on (see accessURL above!). And hey, I defined describedby so I'd like to see it used everywhere - but only where it's the right thing to do which I don't think this is. I can see how you'd force its use, but no overwhelming reason to do so.

A bit of process... a WG member can make a formal objection (http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews) which triggers a Director review. What would happen is that the WG would vote to go to the next stage with the text written in line with the majority view but the Director would then consider the formal objection (raised presumably by the losing party) and take a decision.

Why do I care? Nothing to do with POWDER I assure you. It's because HTTP Link is a good feature of the Web that should never have been removed. It should just be a normal everyday part of any user agent and right now it isn't. I'd like that to change. It would help JSON-LD and many other things too. It keeps coming up and people say "oh well, I'm sure how widely implemented that is..." and go off. Make it useful, use it properly, and people will implement it.

@msporny

This comment has been minimized.

Show comment
Hide comment
@msporny

msporny Nov 15, 2012

Member

O_o - just saw this thread... haven't read it in detail. There seems to be legitimate points on both sides... can we have a back-up plan: Just define a new relationship if describedby and transformation don't work for us? Maybe something like, 'context'? Where the definition of context is something like: 'an external document, when combined with the referring document, results in a deeper interpretation of the contents of the document'?

We may want such a feature for RDFa 2.x, to load a set of external prefixes and terms? Trying to phrase it in a way where other languages can re-use it.

Member

msporny commented Nov 15, 2012

O_o - just saw this thread... haven't read it in detail. There seems to be legitimate points on both sides... can we have a back-up plan: Just define a new relationship if describedby and transformation don't work for us? Maybe something like, 'context'? Where the definition of context is something like: 'an external document, when combined with the referring document, results in a deeper interpretation of the contents of the document'?

We may want such a feature for RDFa 2.x, to load a set of external prefixes and terms? Trying to phrase it in a way where other languages can re-use it.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 15, 2012

What does context mean outside JSON to JSON-LD? If there's an answer for that, then context is a perfect @rel type. If it only has meaning in this context (no pun intended) then I'd say it's a bad one. @rel types should be very generic and certainly not technology-specific. Even 'stylesheet' isn't technology-specific.

ghost commented Nov 15, 2012

What does context mean outside JSON to JSON-LD? If there's an answer for that, then context is a perfect @rel type. If it only has meaning in this context (no pun intended) then I'd say it's a bad one. @rel types should be very generic and certainly not technology-specific. Even 'stylesheet' isn't technology-specific.

@msporny

This comment has been minimized.

Show comment
Hide comment
@msporny

msporny Nov 15, 2012

Member

@philarcher 'context' is an external document that gives you new insight, or a deeper understanding, of the contents of the current document.

Member

msporny commented Nov 15, 2012

@philarcher 'context' is an external document that gives you new insight, or a deeper understanding, of the contents of the current document.

@gkellogg

This comment has been minimized.

Show comment
Hide comment
@gkellogg

gkellogg Nov 15, 2012

Member

We re-examined describedby in the past. I agree that if we can find a better link relationship, we should use it. The problem is, that in some sense, a context does describe a document; the difference is that the document already is metadata, so that the description is more like meta-metadata. But, not in the sense that IANI seems to intended descrdibedby to be used.

+1 to come up with, or find an existing, link relationship term that indicates that the link is to necessary processing information to process it.

Regarding a separate MIME type for context documents, we already has an optional parameter on application/ld+json. The profile, although that might be intended for a different purpose, as a context definitely does change the semantics of the document. But, given that a context is a JSON-LD document, and any JSON-LD document containing a context may be used as the context for another document, using application/ld+json seems right. Perhaps there should be an additional parameter, in which case it should probably match the @rel type.

Member

gkellogg commented Nov 15, 2012

We re-examined describedby in the past. I agree that if we can find a better link relationship, we should use it. The problem is, that in some sense, a context does describe a document; the difference is that the document already is metadata, so that the description is more like meta-metadata. But, not in the sense that IANI seems to intended descrdibedby to be used.

+1 to come up with, or find an existing, link relationship term that indicates that the link is to necessary processing information to process it.

Regarding a separate MIME type for context documents, we already has an optional parameter on application/ld+json. The profile, although that might be intended for a different purpose, as a context definitely does change the semantics of the document. But, given that a context is a JSON-LD document, and any JSON-LD document containing a context may be used as the context for another document, using application/ld+json seems right. Perhaps there should be an additional parameter, in which case it should probably match the @rel type.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 16, 2012

Member

No need to wait for last call @cygri, just as any other issue we will discuss it in one of our next telecons. If the majority of the group thinks that would be a wise thing to do, I simply accept that fact. I was (just as you) expressing my own personal opinion and so far you haven't convinced me that the use case you describe is more important or even clearer than the use case we use describedby for at the moment.

Let me try to explain one more time the reasons why I'm somewhat hesitant to change describedby:

  • the only other rel values that have been mentioned as alternative have been profile and transformation. We had the discussion about profile already and concluded that profile has different semantics. Even Erik Wilde who is the one working on its specification agreed that profile's intended use is different. I also don't think transformation would be a good choice because it is not a transformation in the sense of XSLT as used in GRDDL for instance. Furthermore it is not standardized. I explicitly asked you Richard for an alternative but till now you didn't provide one

  • the way describedby is currently specified does cover our use case; IMO at least. Given that I don't have the final voice on this I sent a mail to the IETF link-relations mailing list asking for their opinion.

  • the official definition of describedby is

    Refers to a resource providing information about the link's context.

  • I think the term "context" covers our use case, but you disagree and refer to the dictionary. Since I know that my English skills aren't perfect, I went and checked myself and found enough examples that apparently seem to cover our use case. The fact that Manu is proposing to use context as alternative relation type tells me that I'm not alone with that interpretation.

  • the way we use describedby only specifies how a JSON-LD processor should interpret a describedby link header found when dereferencing a JSON document. We do not impose any other restrictions. Therefore I don't see how this prevents the use case you are worried about. What should a processor do instead? Go, fetch the referenced JSON-LD document, and output that instead? To make this point even clearer, what should the output of something like this be: JsonLD::expand('http://alice.example.com/addresses.json')

All that being said, I'm still open to be convinced to the contrary. However, convincing me to completely remove this feature will be close to impossible as I think it is way too important.

Member

lanthaler commented Nov 16, 2012

No need to wait for last call @cygri, just as any other issue we will discuss it in one of our next telecons. If the majority of the group thinks that would be a wise thing to do, I simply accept that fact. I was (just as you) expressing my own personal opinion and so far you haven't convinced me that the use case you describe is more important or even clearer than the use case we use describedby for at the moment.

Let me try to explain one more time the reasons why I'm somewhat hesitant to change describedby:

  • the only other rel values that have been mentioned as alternative have been profile and transformation. We had the discussion about profile already and concluded that profile has different semantics. Even Erik Wilde who is the one working on its specification agreed that profile's intended use is different. I also don't think transformation would be a good choice because it is not a transformation in the sense of XSLT as used in GRDDL for instance. Furthermore it is not standardized. I explicitly asked you Richard for an alternative but till now you didn't provide one

  • the way describedby is currently specified does cover our use case; IMO at least. Given that I don't have the final voice on this I sent a mail to the IETF link-relations mailing list asking for their opinion.

  • the official definition of describedby is

    Refers to a resource providing information about the link's context.

  • I think the term "context" covers our use case, but you disagree and refer to the dictionary. Since I know that my English skills aren't perfect, I went and checked myself and found enough examples that apparently seem to cover our use case. The fact that Manu is proposing to use context as alternative relation type tells me that I'm not alone with that interpretation.

  • the way we use describedby only specifies how a JSON-LD processor should interpret a describedby link header found when dereferencing a JSON document. We do not impose any other restrictions. Therefore I don't see how this prevents the use case you are worried about. What should a processor do instead? Go, fetch the referenced JSON-LD document, and output that instead? To make this point even clearer, what should the output of something like this be: JsonLD::expand('http://alice.example.com/addresses.json')

All that being said, I'm still open to be convinced to the contrary. However, convincing me to completely remove this feature will be close to impossible as I think it is way too important.

@tidoust

This comment has been minimized.

Show comment
Hide comment
@tidoust

tidoust Nov 16, 2012

Contributor

On Fri, Nov 16, 2012 at 11:45 AM, Markus Lanthaler <notifications@github.com

wrote:

No need to wait for last call @cygri https://github.com/cygri, just as
any other issue we will discuss it in one of our next telecons. If the
majority of the group thinks that would be a wise thing to do, I simply
accept that fact. I was (just as you) expressing my own personal opinion
and so far you haven't convinced me that the use case you describe is more
important or even clearer than the use case we use describedby for at the
moment.

Let me try to explain one more time the reasons why I'm somewhat hesitant
to change describedby:

the only other rel values that have been mentioned as alternative have
been profile and transformation. We had the discussion about profile
alreadyhttps://github.com/json-ld/json-ld.org/issues/16#issuecomment-6318938and concluded that
profile has different semantics. Even Erik Wilde who is the one
working on its specification agreed that profile's intended use is
differenthttps://github.com/json-ld/json-ld.org/issues/16#issuecomment-6345764.
I also don't think transformation would be a good choice because it is
not a transformation in the sense of XSLT as used in GRDDL for instance.
Furthermore it is not standardized. I explicitly asked you Richard for
an alternativehttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10417618but till now you didn't provide one

Well, Richard and Phil did provide an alternative. That's a "new rel
value". We're writing a Web standard, that's definitely a possible
alternative.

the way describedby is currently specified does cover our use case;
IMO at least. Given that I don't have the final voice on this I sent a mail
to the IETF link-relations mailing listhttp://www.ietf.org/mail-archive/web/link-relations/current/msg00419.htmlasking for their opinion.

It does but that's not the point of this discussion. The problem is
whether it prevents another use case and whether the group thinks it's
important to support that other use case. I suggest we focus on this.

the official definition of describedby is

Refers to a resource providing information about the link's context.

-

I think the term "context" covers our use case, but you disagree and
refer to the dictionaryhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10381794.
Since I know that my English skills aren't perfect, I went and checked
myself and found enough exampleshttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10406601that apparently seem to cover our use case. The fact that Manu is proposing
to use context as alternative relation type tells me that I'm not
alone with that interpretation.

I don't think that matters to the discussion.

the way we use describedby only specifies how a JSON-LD processor
should interpret a describedby link header found when dereferencing a
JSON document. We do not impose any other restrictions. Therefore I don't
see how this prevents the use case you are worried about. What should a
processor do instead? Go, fetch the referenced JSON-LD document, and output
that instead? To make this point even clearer, what should the output of
something like this be: JsonLD::expand('
http://alice.example.com/addresses.json')

Essentially, the use case @cygri is a possible usage of JSON-LD: using
JSON-LD to assert a few statements about other documents. That sounds like
a very valuable usage of JSON-LD. If JSON-LD is used to make statements
about a raw text file available on the Web, the author of the text file
will use a describedby Link from the raw text file to advertise that the
JSON-LD document contains statements about it. That's good, usual tools may
be used to follow links, we're all in the Linked Data world we're trying to
build.

Now replace a "raw text file" by a "JSON document" in the previous
sentence, and we end up with a problem: does JSON-LD document provide its
@context to the initial JSON document or does it assert a few statements
about it? According to the JSON-LD spec, it provides its @context. So how
can a JSON document advertise that the JSON-LD contains a few statements
about it? It cannot for the time being. The author would need to find
another relationship to say so... or the JSON-LD document needs to find
another relationship to enable that use case and let the author use
describedby as usual.

Possible solutions are:

  1. find another relationship or mint a new one. It seems existing ones are
    not perfect.
  2. decide not to support the use case @cygri. I think it's very important
    to support it. If JSON-LD does not play nicely with Linked Data, what spec
    is going to?
  3. drop the feature. That's not an option for me either.

Francois

All that being said, I'm still open to be convinced to the contrary.
However, convincing me to completely remove this feature will be close to
impossible as I think it is way too important.


Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10443247.

Contributor

tidoust commented Nov 16, 2012

On Fri, Nov 16, 2012 at 11:45 AM, Markus Lanthaler <notifications@github.com

wrote:

No need to wait for last call @cygri https://github.com/cygri, just as
any other issue we will discuss it in one of our next telecons. If the
majority of the group thinks that would be a wise thing to do, I simply
accept that fact. I was (just as you) expressing my own personal opinion
and so far you haven't convinced me that the use case you describe is more
important or even clearer than the use case we use describedby for at the
moment.

Let me try to explain one more time the reasons why I'm somewhat hesitant
to change describedby:

the only other rel values that have been mentioned as alternative have
been profile and transformation. We had the discussion about profile
alreadyhttps://github.com/json-ld/json-ld.org/issues/16#issuecomment-6318938and concluded that
profile has different semantics. Even Erik Wilde who is the one
working on its specification agreed that profile's intended use is
differenthttps://github.com/json-ld/json-ld.org/issues/16#issuecomment-6345764.
I also don't think transformation would be a good choice because it is
not a transformation in the sense of XSLT as used in GRDDL for instance.
Furthermore it is not standardized. I explicitly asked you Richard for
an alternativehttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10417618but till now you didn't provide one

Well, Richard and Phil did provide an alternative. That's a "new rel
value". We're writing a Web standard, that's definitely a possible
alternative.

the way describedby is currently specified does cover our use case;
IMO at least. Given that I don't have the final voice on this I sent a mail
to the IETF link-relations mailing listhttp://www.ietf.org/mail-archive/web/link-relations/current/msg00419.htmlasking for their opinion.

It does but that's not the point of this discussion. The problem is
whether it prevents another use case and whether the group thinks it's
important to support that other use case. I suggest we focus on this.

the official definition of describedby is

Refers to a resource providing information about the link's context.

-

I think the term "context" covers our use case, but you disagree and
refer to the dictionaryhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10381794.
Since I know that my English skills aren't perfect, I went and checked
myself and found enough exampleshttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10406601that apparently seem to cover our use case. The fact that Manu is proposing
to use context as alternative relation type tells me that I'm not
alone with that interpretation.

I don't think that matters to the discussion.

the way we use describedby only specifies how a JSON-LD processor
should interpret a describedby link header found when dereferencing a
JSON document. We do not impose any other restrictions. Therefore I don't
see how this prevents the use case you are worried about. What should a
processor do instead? Go, fetch the referenced JSON-LD document, and output
that instead? To make this point even clearer, what should the output of
something like this be: JsonLD::expand('
http://alice.example.com/addresses.json')

Essentially, the use case @cygri is a possible usage of JSON-LD: using
JSON-LD to assert a few statements about other documents. That sounds like
a very valuable usage of JSON-LD. If JSON-LD is used to make statements
about a raw text file available on the Web, the author of the text file
will use a describedby Link from the raw text file to advertise that the
JSON-LD document contains statements about it. That's good, usual tools may
be used to follow links, we're all in the Linked Data world we're trying to
build.

Now replace a "raw text file" by a "JSON document" in the previous
sentence, and we end up with a problem: does JSON-LD document provide its
@context to the initial JSON document or does it assert a few statements
about it? According to the JSON-LD spec, it provides its @context. So how
can a JSON document advertise that the JSON-LD contains a few statements
about it? It cannot for the time being. The author would need to find
another relationship to say so... or the JSON-LD document needs to find
another relationship to enable that use case and let the author use
describedby as usual.

Possible solutions are:

  1. find another relationship or mint a new one. It seems existing ones are
    not perfect.
  2. decide not to support the use case @cygri. I think it's very important
    to support it. If JSON-LD does not play nicely with Linked Data, what spec
    is going to?
  3. drop the feature. That's not an option for me either.

Francois

All that being said, I'm still open to be convinced to the contrary.
However, convincing me to completely remove this feature will be close to
impossible as I think it is way too important.


Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10443247.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 16, 2012

Member

Well, Richard and Phil did provide an alternative. That's a "new rel value". We're writing a Web standard, that's definitely a possible alternative.

I wanted to see a concrete one. I think both transform and profile are not adequate.

Essentially, the use case @cygri is a possible usage of JSON-LD: using JSON-LD to assert a few statements about other documents. That sounds like a very valuable usage of JSON-LD. If JSON-LD is used to make statements about a raw text file available on the Web, the author of the text file will use a describedby Link from the raw text file to advertise that the JSON-LD document contains statements about it. That's good, usual tools may be used to follow links, we're all in the Linked Data world we're trying to build.

Yes, I understand that use case and find it important too.

Now replace a "raw text file" by a "JSON document" in the previous sentence, and we end up with a problem: does JSON-LD document provide its @context to the initial JSON document or does it assert a few statements about it? According to the JSON-LD spec, it provides its @context. So how can a JSON document advertise that the JSON-LD contains a few statements about it? It cannot for the time being. The author would need to find another relationship to say so... or the JSON-LD document needs to find another relationship to enable that use case and let the author use describedby as usual.

Maybe I'm still not clear enough. We are not defining describedby, it is already there. All we are defining is how a JSON-LD processor makes use of such a link when you feed it a JSON document. Other tools may use it differently. I also can't see why you can't embed other statements in the referenced document. The only thing is that, again, a JSON-LD processor would ignore them and just use the context (if there is one). That's all.

Possible solutions are:

  1. find another relationship or mint a new one. It seems existing ones are
    not perfect.

I'm fine with that as long as it matches the semantics and is something that average developers can understand. profile and transform don't fall in that category, context might be even more controversial than describedby.

  1. decide not to support the use case @cygri. I think it's very important
    to support it. If JSON-LD does not play nicely with Linked Data, what spec
    is going to?

Do we really prevent it by saying that a JSON-LD processor will ignore those statements? Nothing prevents you to fetch that link and then just pass the URL of the referenced document to a JSON-LD processor - et voilà, you get your desired statements. Right?

  1. drop the feature. That's not an option for me either.

Good

Member

lanthaler commented Nov 16, 2012

Well, Richard and Phil did provide an alternative. That's a "new rel value". We're writing a Web standard, that's definitely a possible alternative.

I wanted to see a concrete one. I think both transform and profile are not adequate.

Essentially, the use case @cygri is a possible usage of JSON-LD: using JSON-LD to assert a few statements about other documents. That sounds like a very valuable usage of JSON-LD. If JSON-LD is used to make statements about a raw text file available on the Web, the author of the text file will use a describedby Link from the raw text file to advertise that the JSON-LD document contains statements about it. That's good, usual tools may be used to follow links, we're all in the Linked Data world we're trying to build.

Yes, I understand that use case and find it important too.

Now replace a "raw text file" by a "JSON document" in the previous sentence, and we end up with a problem: does JSON-LD document provide its @context to the initial JSON document or does it assert a few statements about it? According to the JSON-LD spec, it provides its @context. So how can a JSON document advertise that the JSON-LD contains a few statements about it? It cannot for the time being. The author would need to find another relationship to say so... or the JSON-LD document needs to find another relationship to enable that use case and let the author use describedby as usual.

Maybe I'm still not clear enough. We are not defining describedby, it is already there. All we are defining is how a JSON-LD processor makes use of such a link when you feed it a JSON document. Other tools may use it differently. I also can't see why you can't embed other statements in the referenced document. The only thing is that, again, a JSON-LD processor would ignore them and just use the context (if there is one). That's all.

Possible solutions are:

  1. find another relationship or mint a new one. It seems existing ones are
    not perfect.

I'm fine with that as long as it matches the semantics and is something that average developers can understand. profile and transform don't fall in that category, context might be even more controversial than describedby.

  1. decide not to support the use case @cygri. I think it's very important
    to support it. If JSON-LD does not play nicely with Linked Data, what spec
    is going to?

Do we really prevent it by saying that a JSON-LD processor will ignore those statements? Nothing prevents you to fetch that link and then just pass the URL of the referenced document to a JSON-LD processor - et voilà, you get your desired statements. Right?

  1. drop the feature. That's not an option for me either.

Good

@tidoust

This comment has been minimized.

Show comment
Hide comment
@tidoust

tidoust Nov 16, 2012

Contributor

On Fri, Nov 16, 2012 at 1:33 PM, Markus Lanthaler
notifications@github.comwrote:

Well, Richard and Phil did provide an alternative. That's a "new rel
value". We're writing a Web standard, that's definitely a possible
alternative.

I wanted to see a concrete one. I think both transform and profile are not
adequate.

Essentially, the use case @cygri is a possible usage of JSON-LD: using
JSON-LD to assert a few statements about other documents. That sounds like
a very valuable usage of JSON-LD. If JSON-LD is used to make statements
about a raw text file available on the Web, the author of the text file
will use a describedby Link from the raw text file to advertise that the
JSON-LD document contains statements about it. That's good, usual tools
may
be used to follow links, we're all in the Linked Data world we're trying
to
build.

Yes, I understand that use case and find it important too.

Now replace a "raw text file" by a "JSON document" in the previous
sentence, and we end up with a problem: does JSON-LD document provide its
@context to the initial JSON document or does it assert a few statements
about it? According to the JSON-LD spec, it provides its @context. So how
can a JSON document advertise that the JSON-LD contains a few statements
about it? It cannot for the time being. The author would need to find
another relationship to say so... or the JSON-LD document needs to find
another relationship to enable that use case and let the author use
describedby as usual.

Maybe I'm still not clear enough. We are not defining describedby, it is
already there. All we are defining is how a JSON-LD processor makes use
of such a link when you feed it a JSON document. Other tools may use it
differently. I also can't see why you can't embed other statements in the
referenced document. The only thing is that, again, a JSON-LD processor
would ignore them and just use the context (if there is one). That's all.

Possible solutions are:

  1. find another relationship or mint a new one. It seems existing ones
    are
    not perfect.

I'm fine with that as long as it matches the semantics and is something
that average developers can understand. profile and transform don't fall in
that category, context might be even more controversial than describedby.

I don't think there exists a perfect term. We'll have to find the one that
displeases people equally, as they say...

  1. decide not to support the use case @cygri. I think it's very important

    to support it. If JSON-LD does not play nicely with Linked Data, what
    spec
    is going to?

Do we really prevent it by saying that a JSON-LD processor will ignore
those statements? Nothing prevents you to fetch that link and then just
pass the URL of the referenced document to a JSON-LD processor - et voilà,
you get your desired statements. Right?

There are two sides to this:

  1. if the referenced JSON-LD document contains statements about the initial
    JSON document and if you pass the initial JSON document to a JSON-LD
    processor, it may well output a (probably weird but still existing) JSON-LD
    document whereas the author actually did not want that JSON document to
    convert into actual Linked Data. In most cases, that will just generate
    nothing. But in some cases, terms will match keys in the initial document,
    and you will have generated a wrong set of statements. That seems
    problematic. A search engine crawling JSON pages would actually have no way
    to know whether the statements they generate from a JSON document are
    intended or not.
  2. if the referenced JSON-LD actually provided its context to the initial
    document and if you pass the initial JSON document to another tool, the
    other tool will process the JSON-LD document and generate the statements it
    contains. Now, I see your point, it may not matter so much if these
    statements are not related to the initial document. It's just that the tool
    will ingest statements that the author did not intend to associate with the
    initial document and discard them afterwards because they do not relate to
    the initial document. You could also imagine that the referenced JSON-LD
    document actually contains statements that relate to the initial document
    but that the author still did not want to expose them, but that's a bit
    convoluted and idiot, granted. In the end, even though it's not harmful,
    it's a waste of resources: it means an additional round-trip, cpu and
    memory used for nothing.

In the end, what bugs me is that we do not provide a way for authors to
distinguish between these two different yet typical use cases.
It seems to me that we should ensure machines can take the right decision
when they follow links.

  1. drop the feature. That's not an option for me either.

Good


Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10445565.

Contributor

tidoust commented Nov 16, 2012

On Fri, Nov 16, 2012 at 1:33 PM, Markus Lanthaler
notifications@github.comwrote:

Well, Richard and Phil did provide an alternative. That's a "new rel
value". We're writing a Web standard, that's definitely a possible
alternative.

I wanted to see a concrete one. I think both transform and profile are not
adequate.

Essentially, the use case @cygri is a possible usage of JSON-LD: using
JSON-LD to assert a few statements about other documents. That sounds like
a very valuable usage of JSON-LD. If JSON-LD is used to make statements
about a raw text file available on the Web, the author of the text file
will use a describedby Link from the raw text file to advertise that the
JSON-LD document contains statements about it. That's good, usual tools
may
be used to follow links, we're all in the Linked Data world we're trying
to
build.

Yes, I understand that use case and find it important too.

Now replace a "raw text file" by a "JSON document" in the previous
sentence, and we end up with a problem: does JSON-LD document provide its
@context to the initial JSON document or does it assert a few statements
about it? According to the JSON-LD spec, it provides its @context. So how
can a JSON document advertise that the JSON-LD contains a few statements
about it? It cannot for the time being. The author would need to find
another relationship to say so... or the JSON-LD document needs to find
another relationship to enable that use case and let the author use
describedby as usual.

Maybe I'm still not clear enough. We are not defining describedby, it is
already there. All we are defining is how a JSON-LD processor makes use
of such a link when you feed it a JSON document. Other tools may use it
differently. I also can't see why you can't embed other statements in the
referenced document. The only thing is that, again, a JSON-LD processor
would ignore them and just use the context (if there is one). That's all.

Possible solutions are:

  1. find another relationship or mint a new one. It seems existing ones
    are
    not perfect.

I'm fine with that as long as it matches the semantics and is something
that average developers can understand. profile and transform don't fall in
that category, context might be even more controversial than describedby.

I don't think there exists a perfect term. We'll have to find the one that
displeases people equally, as they say...

  1. decide not to support the use case @cygri. I think it's very important

    to support it. If JSON-LD does not play nicely with Linked Data, what
    spec
    is going to?

Do we really prevent it by saying that a JSON-LD processor will ignore
those statements? Nothing prevents you to fetch that link and then just
pass the URL of the referenced document to a JSON-LD processor - et voilà,
you get your desired statements. Right?

There are two sides to this:

  1. if the referenced JSON-LD document contains statements about the initial
    JSON document and if you pass the initial JSON document to a JSON-LD
    processor, it may well output a (probably weird but still existing) JSON-LD
    document whereas the author actually did not want that JSON document to
    convert into actual Linked Data. In most cases, that will just generate
    nothing. But in some cases, terms will match keys in the initial document,
    and you will have generated a wrong set of statements. That seems
    problematic. A search engine crawling JSON pages would actually have no way
    to know whether the statements they generate from a JSON document are
    intended or not.
  2. if the referenced JSON-LD actually provided its context to the initial
    document and if you pass the initial JSON document to another tool, the
    other tool will process the JSON-LD document and generate the statements it
    contains. Now, I see your point, it may not matter so much if these
    statements are not related to the initial document. It's just that the tool
    will ingest statements that the author did not intend to associate with the
    initial document and discard them afterwards because they do not relate to
    the initial document. You could also imagine that the referenced JSON-LD
    document actually contains statements that relate to the initial document
    but that the author still did not want to expose them, but that's a bit
    convoluted and idiot, granted. In the end, even though it's not harmful,
    it's a waste of resources: it means an additional round-trip, cpu and
    memory used for nothing.

In the end, what bugs me is that we do not provide a way for authors to
distinguish between these two different yet typical use cases.
It seems to me that we should ensure machines can take the right decision
when they follow links.

  1. drop the feature. That's not an option for me either.

Good


Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10445565.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 16, 2012

Member
  1. if the referenced JSON-LD document contains statements about the initial
    JSON document and if you pass the initial JSON document to a JSON-LD
    processor, it may well output a (probably weird but still existing) JSON-LD
    document whereas the author actually did not want that JSON document to
    convert into actual Linked Data. In most cases, that will just generate
    nothing. But in some cases, terms will match keys in the initial document,
    and you will have generated a wrong set of statements. That seems
    problematic. A search engine crawling JSON pages would actually have no way
    to know whether the statements they generate from a JSON document are
    intended or not.

There are very simple ways to prevent that. The most trivial approach would be to wrap the whole object in an array so that a JSON-LD processor wouldn't find the context anymore. This isn't documented explicitly in the spec yet and we should definitely change that.

  1. if the referenced JSON-LD actually provided its context to the initial
    document and if you pass the initial JSON document to another tool, the
    other tool will process the JSON-LD document and generate the statements it
    contains. Now, I see your point, it may not matter so much if these
    statements are not related to the initial document. It's just that the tool
    will ingest statements that the author did not intend to associate with the
    initial document and discard them afterwards because they do not relate to
    the initial document. You could also imagine that the referenced JSON-LD
    document actually contains statements that relate to the initial document
    but that the author still did not want to expose them, but that's a bit
    convoluted and idiot, granted. In the end, even though it's not harmful,
    it's a waste of resources: it means an additional round-trip, cpu and
    memory used for nothing.

I'm sorry, but I don't think I understand what you outlined above.

There are two actors here, the publisher and the consumer.

The publisher has a JSON document that he wants to "describe" somehow to someone. He either wants to a) describe it in a way that a JSON-LD processor understands it, or b) describe it in a way Richard outlined (without mapping IRIs to the terms used in the JSON document) or c) both. In all three cases he creates an HTTP link header pointing to a JSON-LD document as he doesn't want to change the existing JSON document.

For case a) it's enough if he publishes a context.

For case b) he has to make sure that there's no @context property in the top-level object (if there is one) that contains definitions for terms that are used in the JSON document. He then simply includes the statements he wants to make about the JSON document in the JSON-LD document

For case c) he publishes a context and includes additionally statements about the JSON document in that JSON-LD document.

Now we come to the consumer which might be a) interested in the (linked) data contained in the JSON document, b) in the statements about the JSON document, or c) both.

Case a) is simple. He just fires up his JSON-LD processor by passing the JSON document: JsonLD::expand('http://example.com/data.json')

Case b) is also quite simple: He does a HEAD http://example.com/data.json, looks for a describedby link header and then again, fires up his favourite JSON-LD processor: JsonLD::expand(request.getHeaders('describedBy').href)

Case c) is not much different. Since the consumer is interested in both this time he does a GET http://example.com/data.json, followed by a JsonLD::expand(request.getBody, request.getHeaders('describedBy').href) and a JsonLD::expand(request.getHeaders('describedBy').href).

In the end, what bugs me is that we do not provide a way for authors to
distinguish between these two different yet typical use cases.
It seems to me that we should ensure machines can take the right decision
when they follow links.

That's exactly what I'm not convinced about.

Member

lanthaler commented Nov 16, 2012

  1. if the referenced JSON-LD document contains statements about the initial
    JSON document and if you pass the initial JSON document to a JSON-LD
    processor, it may well output a (probably weird but still existing) JSON-LD
    document whereas the author actually did not want that JSON document to
    convert into actual Linked Data. In most cases, that will just generate
    nothing. But in some cases, terms will match keys in the initial document,
    and you will have generated a wrong set of statements. That seems
    problematic. A search engine crawling JSON pages would actually have no way
    to know whether the statements they generate from a JSON document are
    intended or not.

There are very simple ways to prevent that. The most trivial approach would be to wrap the whole object in an array so that a JSON-LD processor wouldn't find the context anymore. This isn't documented explicitly in the spec yet and we should definitely change that.

  1. if the referenced JSON-LD actually provided its context to the initial
    document and if you pass the initial JSON document to another tool, the
    other tool will process the JSON-LD document and generate the statements it
    contains. Now, I see your point, it may not matter so much if these
    statements are not related to the initial document. It's just that the tool
    will ingest statements that the author did not intend to associate with the
    initial document and discard them afterwards because they do not relate to
    the initial document. You could also imagine that the referenced JSON-LD
    document actually contains statements that relate to the initial document
    but that the author still did not want to expose them, but that's a bit
    convoluted and idiot, granted. In the end, even though it's not harmful,
    it's a waste of resources: it means an additional round-trip, cpu and
    memory used for nothing.

I'm sorry, but I don't think I understand what you outlined above.

There are two actors here, the publisher and the consumer.

The publisher has a JSON document that he wants to "describe" somehow to someone. He either wants to a) describe it in a way that a JSON-LD processor understands it, or b) describe it in a way Richard outlined (without mapping IRIs to the terms used in the JSON document) or c) both. In all three cases he creates an HTTP link header pointing to a JSON-LD document as he doesn't want to change the existing JSON document.

For case a) it's enough if he publishes a context.

For case b) he has to make sure that there's no @context property in the top-level object (if there is one) that contains definitions for terms that are used in the JSON document. He then simply includes the statements he wants to make about the JSON document in the JSON-LD document

For case c) he publishes a context and includes additionally statements about the JSON document in that JSON-LD document.

Now we come to the consumer which might be a) interested in the (linked) data contained in the JSON document, b) in the statements about the JSON document, or c) both.

Case a) is simple. He just fires up his JSON-LD processor by passing the JSON document: JsonLD::expand('http://example.com/data.json')

Case b) is also quite simple: He does a HEAD http://example.com/data.json, looks for a describedby link header and then again, fires up his favourite JSON-LD processor: JsonLD::expand(request.getHeaders('describedBy').href)

Case c) is not much different. Since the consumer is interested in both this time he does a GET http://example.com/data.json, followed by a JsonLD::expand(request.getBody, request.getHeaders('describedBy').href) and a JsonLD::expand(request.getHeaders('describedBy').href).

In the end, what bugs me is that we do not provide a way for authors to
distinguish between these two different yet typical use cases.
It seems to me that we should ensure machines can take the right decision
when they follow links.

That's exactly what I'm not convinced about.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 16, 2012

Member

Sorry, forgot this in the last mail

In the end, even though it's not harmful, it's a waste of resources: it means an additional round-trip, cpu and memory used for nothing.

What exactly did you mean by this statement? That's a general "problem" (please note the quotes around "problem") of RDF as it doesn't expose any semantics at the HTTP level in the form of media types, i.e., there's no way to know what you'll get or express what you want before you actually GET it.

What's the problem if you don't find what you hoped to find? That happens all the time on the Web and you have to be prepared to that anyway. What if you get back statements using a vocabulary you don't understand? Is that any better?

Member

lanthaler commented Nov 16, 2012

Sorry, forgot this in the last mail

In the end, even though it's not harmful, it's a waste of resources: it means an additional round-trip, cpu and memory used for nothing.

What exactly did you mean by this statement? That's a general "problem" (please note the quotes around "problem") of RDF as it doesn't expose any semantics at the HTTP level in the form of media types, i.e., there's no way to know what you'll get or express what you want before you actually GET it.

What's the problem if you don't find what you hoped to find? That happens all the time on the Web and you have to be prepared to that anyway. What if you get back statements using a vocabulary you don't understand? Is that any better?

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 16, 2012

Member

Sorry, forgot this in the last mail

In the end, even though it's not harmful, it's a waste of resources: it means an additional round-trip, cpu and memory used for nothing.

What exactly did you mean by this statement? That's a general "problem" (please note the quotes around "problem") of RDF as it doesn't expose any semantics in the form of media types, i.e., there's no way to know what you'll get before you actually GET it.

What's the problem if you don't find what you hoped to find? That happens all the time on the Web and you have to be prepared to that anyway. What if you get back statements using a vocabulary you don't understand? Is that any better?

Member

lanthaler commented Nov 16, 2012

Sorry, forgot this in the last mail

In the end, even though it's not harmful, it's a waste of resources: it means an additional round-trip, cpu and memory used for nothing.

What exactly did you mean by this statement? That's a general "problem" (please note the quotes around "problem") of RDF as it doesn't expose any semantics in the form of media types, i.e., there's no way to know what you'll get before you actually GET it.

What's the problem if you don't find what you hoped to find? That happens all the time on the Web and you have to be prepared to that anyway. What if you get back statements using a vocabulary you don't understand? Is that any better?

@tidoust

This comment has been minimized.

Show comment
Hide comment
@tidoust

tidoust Nov 16, 2012

Contributor

On Fri, Nov 16, 2012 at 3:10 PM, Markus Lanthaler
notifications@github.comwrote:

  1. if the referenced JSON-LD document contains statements about the
    initial
    JSON document and if you pass the initial JSON document to a JSON-LD
    processor, it may well output a (probably weird but still existing)
    JSON-LD
    document whereas the author actually did not want that JSON document to
    convert into actual Linked Data. In most cases, that will just generate
    nothing. But in some cases, terms will match keys in the initial
    document,
    and you will have generated a wrong set of statements. That seems
    problematic. A search engine crawling JSON pages would actually have no
    way
    to know whether the statements they generate from a JSON document are
    intended or not.

There are very simple ways to prevent that. The most trivial approach
would be to wrap the whole object in an array so that a JSON-LD processor
wouldn't find the context anymore. This isn't documented in the spec yet
and we should definitely change that.

  1. if the referenced JSON-LD actually provided its context to the
    initial
    document and if you pass the initial JSON document to another tool, the
    other tool will process the JSON-LD document and generate the statements
    it
    contains. Now, I see your point, it may not matter so much if these
    statements are not related to the initial document. It's just that the
    tool
    will ingest statements that the author did not intend to associate with
    the
    initial document and discard them afterwards because they do not relate
    to
    the initial document. You could also imagine that the referenced JSON-LD
    document actually contains statements that relate to the initial
    document
    but that the author still did not want to expose them, but that's a bit
    convoluted and idiot, granted. In the end, even though it's not harmful,
    it's a waste of resources: it means an additional round-trip, cpu and
    memory used for nothing.

I'm sorry, but I don't think I understand what you outlined above.

There are two actors here, the publisher and the consumer.

The publisher has a JSON document that he wants to "describe" somehow to
someone. He either wants to a) describe it in a way that a JSON-LD
processor understands it, or b) describe it in a way Richard outlined
(without mapping IRIs to the terms used in the JSON document) or c) both.
In all three cases he creates an HTTP link header pointing to a JSON-LD
document as he doesn't want to change the existing JSON document.

For case a) it's enough if he publishes a context.

For case b) he has to make sure that there's no @context property in the
top-level object (if there is one) that contains definitions for terms that
are used in the JSON document. He then simply includes the statements he
wants to make about the JSON document in the JSON-LD document

I see. That works but hiding the @context to ensure it's not picked up by a
JSON-LD processor seems very hacky. That would easily be missed by authors
even if it's spelled out properly in the spec. Why would we want to force
people to use a specific JSON-LD construct?

Note that this mechanism is similar to using a different "rel" value, only
at a different level. You end up with two profiles of JSON-LD: the full
profile and the "description-only profile" where you must not use a top
level "@context" definition.

For case c) he publishes a context and includes additionally statements
about the JSON document in that JSON-LD document.

Now we come to the consumer which might be a) interested in the (linked)
data contained in the JSON document, b) in the statements about the JSON
document, or c) both.

Case a) is simple. He just fires up his JSON-LD processor by passing the
JSON document: JsonLD::expand('http://example.com/data.json')

Case b) is also quite simple: He does a HEAD http://example.com/data.json,
looks for a describedby link header and then again, fires up his favourite
JSON-LD processor: JsonLD::expand(request.getHeaders('describedBy').href)

Case c) is not much different. Since the consumer is interested in both
this time he does a GET http://example.com/data.json, followed by a
JsonLD::expand(request.getBody, request.getHeaders('describedBy').href) and
a JsonLD::expand(request.getHeaders('describedBy').href).

In the end, what bugs me is that we do not provide a way for authors to
distinguish between these two different yet typical use cases.
It seems to me that we should ensure machines can take the right
decision
when they follow links.

That's exactly what I'm not convinced about.

See above, as far as I can tell, the remaining divergence is about the
level at which the distinction between case a) and b) is applied. I would
personally prefer to see it explicitly stated in the link relationship
rather than having the distinction hidden in an implicit JSON-LD construct.


Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10447880.

Contributor

tidoust commented Nov 16, 2012

On Fri, Nov 16, 2012 at 3:10 PM, Markus Lanthaler
notifications@github.comwrote:

  1. if the referenced JSON-LD document contains statements about the
    initial
    JSON document and if you pass the initial JSON document to a JSON-LD
    processor, it may well output a (probably weird but still existing)
    JSON-LD
    document whereas the author actually did not want that JSON document to
    convert into actual Linked Data. In most cases, that will just generate
    nothing. But in some cases, terms will match keys in the initial
    document,
    and you will have generated a wrong set of statements. That seems
    problematic. A search engine crawling JSON pages would actually have no
    way
    to know whether the statements they generate from a JSON document are
    intended or not.

There are very simple ways to prevent that. The most trivial approach
would be to wrap the whole object in an array so that a JSON-LD processor
wouldn't find the context anymore. This isn't documented in the spec yet
and we should definitely change that.

  1. if the referenced JSON-LD actually provided its context to the
    initial
    document and if you pass the initial JSON document to another tool, the
    other tool will process the JSON-LD document and generate the statements
    it
    contains. Now, I see your point, it may not matter so much if these
    statements are not related to the initial document. It's just that the
    tool
    will ingest statements that the author did not intend to associate with
    the
    initial document and discard them afterwards because they do not relate
    to
    the initial document. You could also imagine that the referenced JSON-LD
    document actually contains statements that relate to the initial
    document
    but that the author still did not want to expose them, but that's a bit
    convoluted and idiot, granted. In the end, even though it's not harmful,
    it's a waste of resources: it means an additional round-trip, cpu and
    memory used for nothing.

I'm sorry, but I don't think I understand what you outlined above.

There are two actors here, the publisher and the consumer.

The publisher has a JSON document that he wants to "describe" somehow to
someone. He either wants to a) describe it in a way that a JSON-LD
processor understands it, or b) describe it in a way Richard outlined
(without mapping IRIs to the terms used in the JSON document) or c) both.
In all three cases he creates an HTTP link header pointing to a JSON-LD
document as he doesn't want to change the existing JSON document.

For case a) it's enough if he publishes a context.

For case b) he has to make sure that there's no @context property in the
top-level object (if there is one) that contains definitions for terms that
are used in the JSON document. He then simply includes the statements he
wants to make about the JSON document in the JSON-LD document

I see. That works but hiding the @context to ensure it's not picked up by a
JSON-LD processor seems very hacky. That would easily be missed by authors
even if it's spelled out properly in the spec. Why would we want to force
people to use a specific JSON-LD construct?

Note that this mechanism is similar to using a different "rel" value, only
at a different level. You end up with two profiles of JSON-LD: the full
profile and the "description-only profile" where you must not use a top
level "@context" definition.

For case c) he publishes a context and includes additionally statements
about the JSON document in that JSON-LD document.

Now we come to the consumer which might be a) interested in the (linked)
data contained in the JSON document, b) in the statements about the JSON
document, or c) both.

Case a) is simple. He just fires up his JSON-LD processor by passing the
JSON document: JsonLD::expand('http://example.com/data.json')

Case b) is also quite simple: He does a HEAD http://example.com/data.json,
looks for a describedby link header and then again, fires up his favourite
JSON-LD processor: JsonLD::expand(request.getHeaders('describedBy').href)

Case c) is not much different. Since the consumer is interested in both
this time he does a GET http://example.com/data.json, followed by a
JsonLD::expand(request.getBody, request.getHeaders('describedBy').href) and
a JsonLD::expand(request.getHeaders('describedBy').href).

In the end, what bugs me is that we do not provide a way for authors to
distinguish between these two different yet typical use cases.
It seems to me that we should ensure machines can take the right
decision
when they follow links.

That's exactly what I'm not convinced about.

See above, as far as I can tell, the remaining divergence is about the
level at which the distinction between case a) and b) is applied. I would
personally prefer to see it explicitly stated in the link relationship
rather than having the distinction hidden in an implicit JSON-LD construct.


Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10447880.

@tidoust

This comment has been minimized.

Show comment
Hide comment
@tidoust

tidoust Nov 16, 2012

Contributor

On Fri, Nov 16, 2012 at 3:23 PM, Markus Lanthaler
notifications@github.comwrote:

Sorry, forgot this in the last mail

In the end, even though it's not harmful, it's a waste of resources: it
means an additional round-trip, cpu and memory used for nothing.

What exactly did you mean by this statement? That's a general "problem"
(please note the quotes around "problem") of RDF as it doesn't expose any
semantics in the form of media types, i.e., there's no way to know what
you'll get before you actually GET it.

Well, in the case of Link, you may expose the media type of the targeted
document with the "type" parameter. That's only a hint and the type is most
surely only marginally used, but that's still something tools could use to
decide whether to pursue the link or not.

What's the problem if you don't find what you hoped to find? That happens
all the time on the Web and you have to be prepared to that anyway. What if
you get back statements using a vocabulary you don't understand? Is that
any better?

As said, my main concern is getting back statements that the author did not
want to make using a vocabulary I understand. That's why I think the
distinction needs to be made. The "hide the top-level @context" solution
would do the trick, I'm just not too keen on "tricks".

Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10448308.

Contributor

tidoust commented Nov 16, 2012

On Fri, Nov 16, 2012 at 3:23 PM, Markus Lanthaler
notifications@github.comwrote:

Sorry, forgot this in the last mail

In the end, even though it's not harmful, it's a waste of resources: it
means an additional round-trip, cpu and memory used for nothing.

What exactly did you mean by this statement? That's a general "problem"
(please note the quotes around "problem") of RDF as it doesn't expose any
semantics in the form of media types, i.e., there's no way to know what
you'll get before you actually GET it.

Well, in the case of Link, you may expose the media type of the targeted
document with the "type" parameter. That's only a hint and the type is most
surely only marginally used, but that's still something tools could use to
decide whether to pursue the link or not.

What's the problem if you don't find what you hoped to find? That happens
all the time on the Web and you have to be prepared to that anyway. What if
you get back statements using a vocabulary you don't understand? Is that
any better?

As said, my main concern is getting back statements that the author did not
want to make using a vocabulary I understand. That's why I think the
distinction needs to be made. The "hide the top-level @context" solution
would do the trick, I'm just not too keen on "tricks".

Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10448308.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 16, 2012

Member

I see. That works but hiding the @context to ensure it's not picked up by a
JSON-LD processor seems very hacky. That would easily be missed by authors
even if it's spelled out properly in the spec. Why would we want to force
people to use a specific JSON-LD construct?

The question is what's the more common use case? Of course I don't have any data but I assume that it will be linking to a context.

See above, as far as I can tell, the remaining divergence is about the
level at which the distinction between case a) and b) is applied. I would
personally prefer to see it explicitly stated in the link relationship
rather than having the distinction hidden in an implicit JSON-LD construct.

Finally we start to agree! :-P

You know my opinion on that. If someone comes up with an acceptable alternative for describedby I'm of course open to give up my position.

Member

lanthaler commented Nov 16, 2012

I see. That works but hiding the @context to ensure it's not picked up by a
JSON-LD processor seems very hacky. That would easily be missed by authors
even if it's spelled out properly in the spec. Why would we want to force
people to use a specific JSON-LD construct?

The question is what's the more common use case? Of course I don't have any data but I assume that it will be linking to a context.

See above, as far as I can tell, the remaining divergence is about the
level at which the distinction between case a) and b) is applied. I would
personally prefer to see it explicitly stated in the link relationship
rather than having the distinction hidden in an implicit JSON-LD construct.

Finally we start to agree! :-P

You know my opinion on that. If someone comes up with an acceptable alternative for describedby I'm of course open to give up my position.

@msporny

This comment has been minimized.

Show comment
Hide comment
@msporny

msporny Nov 16, 2012

Member

@lanthaler You are correct, in that we don't /need/ to mint a new term and could just format the JSON-LD document linked to via describedby in a certain way as to support each use case you outline above. I also don't think that the use of 'context' in 'describedby' is being used in the way that we're using it now... or rather, it's use is vague and could be interpreted in both ways. It's ambiguous. That said, there is a potential for an author to miss this fine point. I don't think @cygri's use case will be very common, but if there is a chance that 'describedby' will be misunderstood, then we should try to find an alternative. Introducing potential ambiguity on the Web, especially wrt. Linked Data is a bad thing. In general, we should try to avoid it.

PROPOSAL 1: Retain the ability to specify a JSON-LD context via the 'Link' HTTP header. Mint a new term for the 'describedby' relationship and register it with the IETF.

PROPOSAL 2: The 'context' relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

Member

msporny commented Nov 16, 2012

@lanthaler You are correct, in that we don't /need/ to mint a new term and could just format the JSON-LD document linked to via describedby in a certain way as to support each use case you outline above. I also don't think that the use of 'context' in 'describedby' is being used in the way that we're using it now... or rather, it's use is vague and could be interpreted in both ways. It's ambiguous. That said, there is a potential for an author to miss this fine point. I don't think @cygri's use case will be very common, but if there is a chance that 'describedby' will be misunderstood, then we should try to find an alternative. Introducing potential ambiguity on the Web, especially wrt. Linked Data is a bad thing. In general, we should try to avoid it.

PROPOSAL 1: Retain the ability to specify a JSON-LD context via the 'Link' HTTP header. Mint a new term for the 'describedby' relationship and register it with the IETF.

PROPOSAL 2: The 'context' relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

@cygri

This comment has been minimized.

Show comment
Hide comment
@cygri

cygri Nov 16, 2012

Some choice quotes from RFC 5988:

[Registered relation types] SHOULD be appropriate to the specificity of the relation type; i.e., if the semantics are highly specific to a particular application, the name should reflect that, so that more general names are available for less specific use.

That's exactly the problem here: JSON-LD tries to overload a general name with highly application-specific semantics.

A link can be viewed as a statement of the form "{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}".

That clears up what the term “context” means in the describedby registration.

Applications that don't wish to register a relation type can use an extension relation type, which is a URI [RFC3986] that uniquely identifies the relation type.

We like things to be identified by URIs around here, don't we?

PROPOSAL 3: The rel=http://www.w3.org/ns/json-ld#context relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

cygri commented Nov 16, 2012

Some choice quotes from RFC 5988:

[Registered relation types] SHOULD be appropriate to the specificity of the relation type; i.e., if the semantics are highly specific to a particular application, the name should reflect that, so that more general names are available for less specific use.

That's exactly the problem here: JSON-LD tries to overload a general name with highly application-specific semantics.

A link can be viewed as a statement of the form "{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}".

That clears up what the term “context” means in the describedby registration.

Applications that don't wish to register a relation type can use an extension relation type, which is a URI [RFC3986] that uniquely identifies the relation type.

We like things to be identified by URIs around here, don't we?

PROPOSAL 3: The rel=http://www.w3.org/ns/json-ld#context relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

@msporny

This comment has been minimized.

Show comment
Hide comment
@msporny

msporny Nov 19, 2012

Member

@cygri - I took the liberty of expanding your proposal to something we could put into the minutes.

PROPOSAL 1: +0.7
PROPOSAL 2: +0.6
PROPOSAL 3: +1

Member

msporny commented Nov 19, 2012

@cygri - I took the liberty of expanding your proposal to something we could put into the minutes.

PROPOSAL 1: +0.7
PROPOSAL 2: +0.6
PROPOSAL 3: +1

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 19, 2012

Member

I know that http://www.w3.org/ns/json-ld doesn't have to be dereferenceable but we should practice what we preach, so my question is: What can we put up there? Will we have support for conneg?

I would like it to dereference to a JSON-LD or HTML document depending on the Accept-header. The content would basically just be a description of the feature. Is that be possible? Who can we ask?

Member

lanthaler commented Nov 19, 2012

I know that http://www.w3.org/ns/json-ld doesn't have to be dereferenceable but we should practice what we preach, so my question is: What can we put up there? Will we have support for conneg?

I would like it to dereference to a JSON-LD or HTML document depending on the Accept-header. The content would basically just be a description of the feature. Is that be possible? Who can we ask?

@tidoust

This comment has been minimized.

Show comment
Hide comment
@tidoust

tidoust Nov 19, 2012

Contributor

On Mon, Nov 19, 2012 at 10:46 AM, Markus Lanthaler <notifications@github.com

wrote:

I know that http://www.w3.org/ns/json-ld doesn't have to be
dereferenceable but we should practice what we preach, so my question is.
What can we put up there? Will we have support for conneg?

The following document describes W3C namespaces guidelines:
http://www.w3.org/2005/07/13-nsuri

Conneg is not explicitly mentioned in these guidelines but it is actually
encouraged: "A Namespace Document describes the namespace, providing
directly or by reference information for human and also, ideally, machine
consumption
".

From a technical point of view, W3C servers are already setup to support
conneg, so things should be easy on that front.

I would like it to dereference to a JSON-LD or HTML document depending on

the Accept-header. The content would basically just be a description of the
feature. Is that be possible? Who can we ask?

The right person to ask would be the W3C Staff contact for the RDF WG,
meaning Ivan or Sandro.


Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10507708.

Contributor

tidoust commented Nov 19, 2012

On Mon, Nov 19, 2012 at 10:46 AM, Markus Lanthaler <notifications@github.com

wrote:

I know that http://www.w3.org/ns/json-ld doesn't have to be
dereferenceable but we should practice what we preach, so my question is.
What can we put up there? Will we have support for conneg?

The following document describes W3C namespaces guidelines:
http://www.w3.org/2005/07/13-nsuri

Conneg is not explicitly mentioned in these guidelines but it is actually
encouraged: "A Namespace Document describes the namespace, providing
directly or by reference information for human and also, ideally, machine
consumption
".

From a technical point of view, W3C servers are already setup to support
conneg, so things should be easy on that front.

I would like it to dereference to a JSON-LD or HTML document depending on

the Accept-header. The content would basically just be a description of the
feature. Is that be possible? Who can we ask?

The right person to ask would be the W3C Staff contact for the RDF WG,
meaning Ivan or Sandro.


Reply to this email directly or view it on GitHubhttps://github.com/json-ld/json-ld.org/issues/197#issuecomment-10507708.

@msporny

This comment has been minimized.

Show comment
Hide comment
@msporny

msporny Nov 19, 2012

Member

We already do something like this for RDFa, so there is a precedent.

Member

msporny commented Nov 19, 2012

We already do something like this for RDFa, so there is a precedent.

@niklasl

This comment has been minimized.

Show comment
Hide comment
@niklasl

niklasl Nov 20, 2012

Member

I am in favour of a new IRI unless anyone manages to dig up something existing. It's a pity that neither transformation nor profile are media-type agnostic enough. What might become a pity is if we do the same, and define something too narrow and specific. Especially if we also get it registered as an IANA link relation (since I believe the proliferation of that may hurt general web interoperability).

Member

niklasl commented Nov 20, 2012

I am in favour of a new IRI unless anyone manages to dig up something existing. It's a pity that neither transformation nor profile are media-type agnostic enough. What might become a pity is if we do the same, and define something too narrow and specific. Especially if we also get it registered as an IANA link relation (since I believe the proliferation of that may hurt general web interoperability).

@tidoust

This comment has been minimized.

Show comment
Hide comment
@tidoust

tidoust Nov 20, 2012

Contributor

Agree with @niklasl. I also note the link relationship is only available to users that know how to tweak HTTP headers. No matter how simple this may sound, that remains something technical. In that context, I don't think it is such a big deal to require using an IRI instead of a simple word.

PROPOSAL 1: +1 without the new term registered with the IETF
PROPOSAL 2: -0.5
PROPOSAL 3: +1

Contributor

tidoust commented Nov 20, 2012

Agree with @niklasl. I also note the link relationship is only available to users that know how to tweak HTTP headers. No matter how simple this may sound, that remains something technical. In that context, I don't think it is such a big deal to require using an IRI instead of a simple word.

PROPOSAL 1: +1 without the new term registered with the IETF
PROPOSAL 2: -0.5
PROPOSAL 3: +1

@gkellogg

This comment has been minimized.

Show comment
Hide comment
@gkellogg

gkellogg Nov 20, 2012

Member

PROPOSAL 1: +1
PROPOSAL 2: -0.5
PROPOSAL 3: +1

Member

gkellogg commented Nov 20, 2012

PROPOSAL 1: +1
PROPOSAL 2: -0.5
PROPOSAL 3: +1

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 20, 2012

Member

RESOLVED: Retain the ability to specify a JSON-LD context via the 'Link' HTTP header.

RESOLVED: The rel http://www.w3.org/ns/json-ld#context relationship replaces the describedby relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

Member

lanthaler commented Nov 20, 2012

RESOLVED: Retain the ability to specify a JSON-LD context via the 'Link' HTTP header.

RESOLVED: The rel http://www.w3.org/ns/json-ld#context relationship replaces the describedby relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 21, 2012

Member

For the sake of completeness (and not in an attempt to reopen this issue!) here's the response from Mark Nottingham regarding the use of the describedby link relation:


First of all, link relations are explicitly NOT linked to any particular media type -- so the argument that describedBy is exclusive to POWDER -- assuming that means a media type -- is misfounded.

Indeed, POWDER itself says:

This is a generic relationship type that does not of itself imply that the link points to a POWDER document — that is done by the specific Media type.

The definition of describedBy is:

Refers to a resource providing information about the link's context.

That's it. This is quite vague; some relations are.

Personally, it if were me, I'd want a relation type that is more concrete, but if describedBy works for you, go for it, I'd say.

Cheers

Member

lanthaler commented Nov 21, 2012

For the sake of completeness (and not in an attempt to reopen this issue!) here's the response from Mark Nottingham regarding the use of the describedby link relation:


First of all, link relations are explicitly NOT linked to any particular media type -- so the argument that describedBy is exclusive to POWDER -- assuming that means a media type -- is misfounded.

Indeed, POWDER itself says:

This is a generic relationship type that does not of itself imply that the link points to a POWDER document — that is done by the specific Media type.

The definition of describedBy is:

Refers to a resource providing information about the link's context.

That's it. This is quite vague; some relations are.

Personally, it if were me, I'd want a relation type that is more concrete, but if describedBy works for you, go for it, I'd say.

Cheers

lanthaler added a commit that referenced this issue Nov 21, 2012

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Nov 21, 2012

Member

I updated the spec in 6f0bc8b to use the http://www.w3.org/ns/json-ld#context link relation instead of describedby.

If I do not hear any objections within the next 24 hours I will go ahead and close this issue.

Member

lanthaler commented Nov 21, 2012

I updated the spec in 6f0bc8b to use the http://www.w3.org/ns/json-ld#context link relation instead of describedby.

If I do not hear any objections within the next 24 hours I will go ahead and close this issue.

lanthaler added a commit that referenced this issue Nov 21, 2012

@lanthaler lanthaler closed this Nov 22, 2012

@chrysn chrysn referenced this issue in core-wg/resource-directory Jan 25, 2018

Closed

Version parameter #83

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment