Re: Document fragment vocabulary

Hi Michael and Alex,
sorry to answer so late, I was in holiday in France.
I looked at the three provided resources [1,2,3] and there are still 
some comments and questions I have.

1. The part after the # is actually not sent to the server. Are there 
any solutions for this? It is not really LinkedData friendly.
Compare 
|http://linkedgeodata.org/triplify/near/*51*.*033333*,*13*.*733333*/*1000*/class/Amenity
(Currently not working, but it gives all points within a 1000m radius)
|
The client would be required to calculate the subset of triples from the 
resource, that are addressed.

2. [1] is quite basic and they are basically using position and lines. I 
made a qualitative comparison of different fragment id approaches for 
text in [4] slide 7.
I was wondering if anybody has researched such properties of URI 
fragments. Currently, I am benchmarking stability of these uris using 
Wikipedia changes.
Has such work been done before?

3. @Alex: In my opinion, your proposed fragment ontology can  only be 
used to provide documentation for different fragments.
I would rather propose to just use one triple:
<http://www.w3.org/DesignIssues/LinkedData.html#offset__14406-14418> a 
<http://nlp2rdf.lod2.eu/schema/string/OffsetBasedString>
The ontology I made for Strings might be generalized for formats other 
than text based [5]
One triple is much shorter. As you can see I also tried to encode the 
type of fragment right into the fragment "offset", although a notation 
like "type=offset"  might be better.

4.  @Michael: is there some standardisation respective URIs for text  
going on?
I heard there would be a Language Technology W3C group. The approach by 
Wilde and Dürst[1] seems to lack stability.
Do you think we could do such standardisation for document fragments and 
text fragments within the Media Fragments Group[3] ?
I really thought the liveUrl project was quite good, but it seems dead[6].


In LOD2[7] and NIF[8] we will need some fragment identifiers to 
Standardize NLP tools for the LOD2 stack.
It would be great to reuse stuff instead of starting from scratch. I had 
to extend [1] for example, because it did not produce stable uris and 
also it did not contain the type of algorithm used to produce the URI.

All the best,
Sebastian


[1] http://tools.ietf.org/html/rfc5147
[2] http://tools.ietf.org/html/draft-hausenblas-csv-fragment
[3] http://www.w3.org/TR/media-frags/
[4] http://www.slideshare.net/kurzum/nif-nlp-interchange-format
[5] http://nlp2rdf.lod2.eu/schema/string/
[6] http://liveurls.mozdev.org/index.html
[7] http://lod2.eu
[8] http://aksw.org/Projects/NIF

Am 04.08.2011 22:37, schrieb Michael Hausenblas:
>
> Alex,
>
>> Has something already done this? Is it even (mostly?) sane?
>
> Sane yes, IMO. Done, sort of, see:
>
> + URI Fragment Identifiers for the text/plain [1]
> + URI Fragment Identifiers for the text/csv [2]
>
> Cheers,
>     Michael
>
> [1] http://tools.ietf.org/html/rfc5147
> [2] http://tools.ietf.org/html/draft-hausenblas-csv-fragment
>
> -- 
> Dr. Michael Hausenblas, Research Fellow
> LiDRC - Linked Data Research Centre
> DERI - Digital Enterprise Research Institute
> NUIG - National University of Ireland, Galway
> Ireland, Europe
> Tel. +353 91 495730
> http://linkeddata.deri.ie/
> http://sw-app.org/about.html
>
> On 4 Aug 2011, at 14:22, Alexander Dutton wrote:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi all,
>>
>> Say I have an XML document, <http://example.org/something.xml>, and I
>> want to talk about about some part of it in RDF. As this is XML, being
>> able to point into it using XPath sounds ideal, leading to something 
>> like:
>>
>> <#fragment> a fragment:Fragment ;
>>  fragment:within <http://example.org/something.xml> ;
>>  fragment:locator "/some/path[1]"^^fragment:xpath .
>>
>> (For now we can ignore whether we wanted a nodeset or a single node,
>> and how to handle XML namespaces.)
>>
>> More generally, we might want other ways of locating fragments
>> (probably with a datatype for each):
>>
>> * character offsets / ranges
>> * byte offsets / ranges
>> * line numbers / ranges
>> * some sub-rectangle of an image
>> * XML node IDs
>> * page ranges of a paginated document
>>
>> Some of these will be IMT-specific and may need some more thinking
>> about, but the idea is there.
>>
>>
>> Has something already done this? Is it even (mostly?) sane?
>>
>>
>> Yours,
>>
>> Alex
>>
>>
>> NB. Our actual use-case is having pointers into an NLM XML file
>> (embodying a journal article) so we can hook up our in-text reference
>> pointer¹ URIs to the original XML elements (<xref/>s) they were
>> generated from. This will allow us to work out the context of each
>> citation for use in further analysis of the relationship between the
>> citing and cited articles.
>>
>> ¹ See
>> <http://opencitations.wordpress.com/2011/07/01/nomenclature-for-citations-and-references/> 
>>
>> for an explanation of the terminology.
>>
>> - -- 
>> Alexander Dutton
>> Developer, data.ox.ac.uk, InfoDev, Oxford University Computing Services
>>           Open Citations Project, Department of Zoology, University
>> of Oxford
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk46nS4ACgkQS0pRIabRbjDVZQCdGblvoMgNqEietlE5EwAkPJY8
>> pikAn2KApM0HjcXj6TZegA+Dek/DJIQX
>> =UcCr
>> -----END PGP SIGNATURE-----
>>
>>
>
>


-- 
Dipl. Inf. Sebastian Hellmann
Department of Computer Science, University of Leipzig
Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann
Research Group: http://aksw.org