W3C home > Mailing lists > Public > public-rdf-wg@w3.org > December 2013

RE: Concepts (almost) ready

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 17 Dec 2013 18:26:46 +0100
To: "'RDF WG'" <public-rdf-wg@w3.org>
Message-ID: <03c401cefb4d$2ab54760$801fd620$@lanthaler@gmx.net>
I've now updated Concepts as explained below:

> On Tuesday, December 17, 2013 10:40 AM, Richard Cyganiak wrote:
> > > On 17 Dec 2013, at 05:25, Pat Hayes <phayes@ihmc.us> wrote:
> [...]
> > > 1.2  "Unlike IRIs...blank nodes do not denote specific resources."  I
> > > know we have been through this before, but this statement still makes me
> > > shiver, because blank nodes *do* denote resources, just as IRIs do, so a
> > > very large burden is being placed here on that word "specific". This
> > > would be both more accurate and read better if it said "..do not
> > > identify specific resources". The document does use "identify " in this
> > > sense in other places (eg 1.3), and it is widely used in the sense in
> > > other foundational Web documents, in particular the WebArch document
> > > which discusses IRI collisions.
> 
> I'm fine with replacing
> 
>   "Unlike IRIs and literals, blank nodes do not *denote* specific resources"
> 
> with
> 
>   "Unlike IRIs and literals, blank nodes do not *identify* specific resources"

Done. Since we have a similar denote/identify discussion going on, could people please have a look at this.


> We could perhaps also clarify it by adding a
> 
>   "... but simply indicate the existence of some unknown resource"
> 
> (perhaps with a better word for "indicate")

Didn't add this.


> > > 1.5 "It does not deal with time, and..." I think this is better
> > omitted. It could be misunderstood as denying the following paragraph.
> > The rest of the sentence says what needs to be said more clearly.
> > 
> > Would be fine with me.
> 
> +1

Done

 
> > > ?? 1.6  Might it be helpful to put an informative reference to
> > Antoine's semantic survey right after "There are many possible uses for
> > RDF datasets." ?
> > 
> > +1, the document should absolutely be referenced somewhere,
> 
> Yeah, but this is probably not the right place as Antoine's document doesn't talk about use cases but possible semantics. I would propose to add something like the following sentence to the note in section 4:
> 
>   A discussion of different RDF Dataset semantics can be found in [RDF11-DATASETS].

Added to section 4, not to section 1.6

 
> > > 4.  "Blank nodes MAY be shared between graphs in an RDF dataset."
> > Um, I now see that this can be understood in different ways. What I
> > think (hope) is intended here is, that if the same bnodeID is used in
> > two graph documents in the same dataset, then that means that those two
> > graphs do share a bnode. But what it could be read as saying is that
> > whether or not they share the bnode is optional: they might or they
> > might not. Which would be a very unfortunate reading.
> > 
> > You are right.
> > 
> > How about simply lowercasing the MAY? It's not meant as something
> > that's optional for conformance, but simply to indicate a possibility.
> > So, MAY in the RFC2119 sense is inappropriate.
> > 
> > Alternatively, “can be shared”.
> 
> +1 to "can be shared".

Change to "can be shared".


> > > [[IMPORTANT]]  In the Note:  "... the graph name does not formally
> > denote the graph."  This is wrong as stated, and kind of dangerous in a
> > normative section as it seems to prohibit graph names from *ever*
> > denoting graphs. Also the use of "formally" seems to suggest two kinds
> > of denotation (formal and informal) which is misleading. Any of these
> > alternatives would work:
> > >
> > > the graph name need not denote the graph.
> > > the graph name is not required to denote the graph.
> > > RDF does not require the graph name to denote the graph.
> > 
> > I like the last two options.
> 
> The second option flows the best when inserted in the text IMO.

Replaced with the second option above.


--
Markus Lanthaler
@markuslanthaler
Received on Tuesday, 17 December 2013 17:27:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:37 UTC