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

Re: Regarding 6. Fragment Identifiers in http://www.w3.org/TR/2013/WD-rdf11-concepts-20130723/#section-fragID (tracker, this is on ISSUE-141)

From: Ivan Herman <ivan@w3.org>
Date: Wed, 11 Sep 2013 18:23:12 +0200
Cc: public-rdf-comments@w3.org, W3C RDF WG <public-rdf-wg@w3.org>
Message-Id: <94808B45-99BC-4B32-B6A1-E1B9AE4F8A9C@w3.org>
To: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>

this is not a direct answer to your questions, rather a slightly administrative one. The admin issue is indeed that the RDF 1.1 Concepts document is currently in Last Call, and we hope to go to CR very soon. This requires all open issues to be closed. Your question also ended on our issue list as if it was a request for change on the RDF 1.1 Concept Last Call Draft. Is our interpretation correct that you do not request any change on the RDFa 1.1 document and your mail was asking more general question to the RDF WG members? It would be important to have that on record.

B.t.w., reading through your questions I have the impression that these are general questions on the meaning of fragment ID-s and URI-s, and I am afraid these issues are more in the realm of the TAG than in the RDF Working Group. RDF regards URI-s, and therefore fragment ID-s, as essentially opaque identifiers (note that the relevant section in the draft[1] is actually non-normative!).


Ivan Herman
(In the name of the RDF WG)

[1] http://www.w3.org/TR/2013/WD-rdf11-concepts-20130723/#section-fragID

On Aug 23, 2013, at 16:44 , Sebastian Hellmann <hellmann@informatik.uni-leipzig.de> wrote:

> Hello all,
> during my talk to Ivan (see other email) he pointed me to the changes made in the new working draft regarding the section Fragment Identifier.
> Current recommendation: http://www.w3.org/TR/rdf-concepts/#section-fragID
> New draft: http://www.w3.org/TR/2013/WD-rdf11-concepts-20130723/#section-fragID
> Actually, I could live quite well with the old recommendation, but I have some questions regarding the new draft section.
> Especially, I was looking at:
> http://www.w3.org/2004/02/skos/core#Collection 
> It 303 redirects to HTML anchor within a table row at http://www.w3.org/2009/08/skos-reference/skos.html#Collection:
>     <tr>
>       <th colspan="2"><a id="Collection" href="#Collection">skos:Collection</a> </th>
>     </tr>
> Q1: to what does #Collection actually refer to? The anchor element, the text in the element or the whole tree, i.e. the current element, the text and all subelements , ok it's not very deep here, but you know what I mean. There is a difference, between a single node in a tree, the attributes of this node, the content of this node and the subtree with the node at its head. 
> Q2:
>> the fragment chapter1 may identify a document section via the semantics of HTML's @name or @id attributes. The IRI <#chapter1> should then be taken to denote that same section in any RDFa-encoded triples within the same document. Similarly, if the @xml:id attribute [XML-ID] is used in an RDF/XML document, then the corresponding IRI should be taken to denote an XML element.
> I am quite sure that the IRI http://www.w3.org/2004/02/skos/core#Collection  denotes more than the above mentioned anchor element. Is the sentence in the new working draft only relevant for RDFa+XTHML  ?
> Q3: Does a fragment identifier in an application/rdf+xml or text/turtle  information resource refer to (1) the actual content in the file or (2) the IRI in the RDF Graph or (3) the external "thing" or all three of them? Looking at http://www.w3.org/TR/skos-reference/skos.rdf#Collection . Is this now something in line 53 <rdf:Description rdf:about="#Collection"> or "A collection of concepts"
> Q4: Reading the old recommendation, use of fragment id for text/plain (RFC 5147) in the RDF based NLP Interchange Format[1] was consistent. With the new text I am not sure.
> Is there anything wrong with this in RDF 1.1:
> Case 1: 
> curl -H "Accept: application/rdf+xml" "http://nlp2rdf.lod2.eu/nif-ws.php?informat=text&input=My+favourite+actress+is+Natalie+Portman#char=0,39"
> (note that the URI http://nlp2rdf.lod2.eu/nif-ws.php?informat=text&input=My+favourite+actress+is+Natalie+Portman#char=0,39 denotes the Unicode character sequence  in the nif:isString property.) . 
> <?xml version="1.0" encoding="UTF-8"?>
> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>   xmlns:nif="http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#">
>   <rdf:Description rdf:about="http://nlp2rdf.lod2.eu/nif-ws.php?informat=text&amp;input=My+favourite+actress+is+Natalie+Portman#char=0,39">
>     <rdf:type rdf:resource="http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#RFC5147String"/>
>     <rdf:type rdf:resource="http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#Context"/>
>     <nif:beginIndex>0</nif:beginIndex>
>     <nif:endIndex>39</nif:endIndex>
>     <nif:isString>My favourite actress is Natalie Portman</nif:isString>
>   </rdf:Description>
> </rdf:RDF>      
> Case 2:
> curl -H "Accept: text/plain" "http://nlp2rdf.lod2.eu/nif-ws.php?informat=text&input=My+favourite+actress+is+Natalie+Portman#char=0,39"
> returns 39 characters: 
> "My favourite actress is Natalie Portman"
> Sorry, if this has been discussed before.
> All the best,
> Sebastian
> [1] http://svn.aksw.org/papers/2013/ISWC_NIF/public.pdf
> -- 
> Dipl. Inf. Sebastian Hellmann
> Department of Computer Science, University of Leipzig 
> Events: 
> * NLP & DBpedia 2013 (http://nlp-dbpedia2013.blogs.aksw.org, Extended Deadline: *July 18th*)
> * LSWT 23/24 Sept, 2013 in Leipzig (http://aksw.org/lswt) 
> Venha para a Alemanha como PhD: http://bis.informatik.uni-leipzig.de/csf
> Projects: http://nlp2rdf.org , http://linguistics.okfn.org , http://dbpedia.org/Wiktionary , http://dbpedia.org
> Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann
> Research Group: http://aksw.org

Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Wednesday, 11 September 2013 16:23:43 UTC

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