Re: Comments on RDF Concepts

Thanks, Markus.  Responses below.

On Jul 1, 2013, at 13:36, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> Hi all,
> 
> I had a look at the latest version of RDF Concepts and have a couple of
> comments and suggestions:
> 
> Linked Data is not mentioned at all in the document. Given the perma-thread
> we just had I think it should at least be said once that RDF can be used to
> create Linked Data. Maybe after this sentence:
> 
>    Perhaps the most important characterisitic of IRIs in web
>    architecture is that they can be dereferenced, and hence serve as
>    starting points for interactions with a remote server


Yes, good idea.  Done.

> 
> There's also a typo in that sentence
> 
> s/characterisitic/characteristic/

Fixed.

> 
> 
> Can we drop the "universe of discourse" or replace it with something a bit
> more common?

I have changed the first use to:
[[
Any IRI or literal denotes some thing in the real or virtual worlds (the "universe of discourse").
]]

Does that work for everyone?

> 
> 
>    The IRIs in an RDF vocabulary often share a common substring known
>    as a namespace IRI.
> 
> It would probably be better to say "often *begin* with a common substring"

Yes, that is more clear and technically more accurate.  Changed.

> 
> 
> In section 1.4 RDF Vocabularies and Namespace IRIs, what's the point of
> linking to the Primer?

Because (as it says) the Primer will provide a list of commonly used namespace IRIs.  This is a particularly useful thing to do in the Primer as it is one of the most common questions from new users of RDF.

> 
> 
>    In some contexts it is common to abbreviate IRIs that start with
>    namespace IRIs by using the associated namespace prefix.
> 
> In which contexts? It probably better to say that in some
> situations/contexts it is easier/beneficial/... because it makes the data
> more readable.

Sure.  I changed it to:
[[
In some serialization formats it is common to abbreviate IRIs that start with namespace IRIs by using the associated namespace prefix in order to assist readability.
]]

Does that work for you?

> 
> 
> Can we add JSON-LD to the list of concrete RDF syntaxes in section 1.8 RDF
> Documents and Syntaxes?

Yes!  Good catch.

However, the reference needs an update and mine didn't seem to take.  Can someone tell me why?

> 
> 
> Can we (re)move sections 1.7 Equivalence, Entailment and Inconsistency and
> 3.6 Graph Isomorphism, and 4.1 RDF Dataset Isomorphism (to Semantics)?

I appreciate what you are trying to do with regards to simplifying the document.  There are some separations between the Primer, Concepts and Semantics that appear to be rather arbitrary and this is certainly one.  However, I am reluctant to perform major surgery at the moment because we need to get to LC.  I remain open to discussing editorial changes to these sections and, if they are deemed to editorial by the group, to work with the Semantics editors to move some bits of them.

In the interim, I have added some softer language defining isomorphism and removed that term from the section headers of 3.6 and 4.1 as Andy suggested.  I have used the term "comparison" in the section headers in the hope that won't be problematic.

Can that suffice to get us into LC?

> 
> 
> Can we merge section 5.5 The Value Corresponding to a Literal into section
> 3.3 Literals?

It would be nice to merge those two sections.  The problem is that several terms (lexical space, lexical-to-value mapping) aren't defined until Section 5 (Datatypes), but it makes sense to talk about (simple) literals early.  It is also best to avoid forward references (e.g. from 3.3 to 5.5).

So, we have a choice between accepting forward references or cleaning up the literal sections.

I opted to collapse the literal definitions into Section 3.3, after much gnashing of teeth, and to accept the forward references in relation to the datatype terms.  Hopefully it is better.

Regards,
Dave
--
http://about.me/david_wood


> 
> 
> Cheers,
> Markus
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
>