RE: comments on the json-ld document

> > "Linked Data is a set of documents, each containing a representation
> of a linked data graph"
> >
> > Is the word 'document' really good here? Most people, when seeing
> this term, would consider a web page, or a PDF page... I would use
> 'resources' here.
> 
> This might be getting a bit technical for the intended audience.
> Perhaps a parenthetical that describes document as " (resources such as
> web pages, PDF files, or other JSON serializations)".

+1, perhaps we should change it to

Linked Data is a set of resources such as JSON-LD documents, each containing
a representation of a linked data graph


> > So what is the relationship of the semantic web and linked data?
> Section 2.4 says "The semantic web, just like the document-based web,
> uses IRIs for unambiguous identification." which then comes a little
> bit out of the blue.
> 
> Good point, we should be consistent in our terminology. I'd suggest we
> try to remove explicit use of "semantic web", except in some section
> that might describe the relationship between linked data and the
> semantic web. I think the main difference is that SemWeb has some
> imposed representational restrictions and does not necessarily require
> follow-your-nose retrieval of referenced IRIs.

I've tried to get an understanding of the difference of the SemWeb and
Linked Data quite some time ago (http://bit.ly/gYr8iB) and it wasn't that
clear. So I would just propose to drop "Semantic" Web altogether.


> > It is the first time I see the term "Web Vocabulary" (later in 2.4).
> Why not simply "Vocabulary"?

Good point.


> > Third example in 3.1 seems to be misleading in the text. This is not
> a prefix...
> 
> Yes, should be "foaf:name".

This has already been fixed.


> > Beginning of 3.1, it says "In the example above, the key
> http://xmlns.com/foaf/0.1/name is interpreted as an IRI, as opposed to
> being interpreted as a string." What are the rules to turn this into an
> IRI instead of a string? Is it based on the regexp for URI-s? But, if
> those are used, then why needing a coersion rule for the similar
> functionality in case of objects?
> 
> Keys are turned into IRIs if they are not keywords (i.e., @iri, @type,
> .) and result in an absolute IRI after term/prefix expansion. This
> should be made more explicit.

+1


> > I was looking for some precise rules on the where the definition of a
> @context would apply. I would expect something like "the rules in
> @context are valid in the enclosing object and the other descendents of
> the enclosing object". For example
> >
> > {
> >  @context { "a" : "http://..."}
> >  ...
> >  "a" : {
> >           "a" : "http://...."
> >        }
> > }
> >
> > means that "a" is expanded in both the top and the enclosed object.
> >
> > However, you have an example saying
> >
> > {
> >  @context {
> >      "name": "http://xmlns.com/foaf/0.1/name",
> >      "homepage": "http://xmlns.com/foaf/0.1/homepage",
> >      "@coerce":
> >      {
> >         "@iri": "homepage"
> >      }
> >  }
> >  ...
> > }
> >
> > ie, the expansion of "homepage" is also valid in @coerce, which is
> not explained by the rule above.

This should be made more explicit


> > Reading 3.11, I do not understand it. What is the role of @subject in
> the outer object in the first example?
> 
> This is certainly awkward, as has been noted by others. A key is
> necessary to begin the expansion of it's values. Note that in Manu's
> proposed change, the array of objects could be treated as multiple
> subjects to apply to the (nonexistent) key/values at the same level as
> the @subject definition. Note that we've also considered collapsing
> @subject and @iri (into just @iri, I would hope), which wouldn't help
> in this particular case, but it is consistent with the use of @iri to
> describe a single object.

We should really address this issue as the markup is more than confusing.


> > In general, I do not understand what framing tries to achieve. There
> is no explanation in the text; more precisely, I do not understand the
> introductory text. I am asking the question that I am also asking below
> re other features: do we need it for the majority of users?

This should be discussed. We already discussed in the last telecon to drop
the form=frame MIME type variant. Perhaps we should also split the spec in
two parts, JSON-LD and JSON-LD API/Processing


> > Section 4.6 I am fairly opposed the idea of overriding keywords. That
> is really a rope to hang ourselves in terms of readability of a
> dataset. Also, what are the consequences if the context file is read
> from the web as an external file? Doesn't it radically change the
> interpretation of a specific JSON-LD file with or without an access to
> that context?
> 
> This is actually a bit wrong, we're not actually overriding the meaning
> of @subject or @type, but allowing aliases for those keys that affect
> the processing algorithm. I think that it should be an error to
> override @subject, @type, @iri, etc.

Is this really aliasing? Then the spec is completely misleading about this
as it always talks about *overriding keywords*.



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 30 August 2011 23:17:59 UTC