It is not really LinkedData friendly.
Why?
@Michael: is there some standardisation respective URIs for text
going on?
As you've rightly identified, an RFC already exists. What would this
new standardisation activity be chartered for?
As and aside, this reminds me a bit of http://xkcd.com/927/
The approach by Wilde and Dürst[1] seems to lack stability.
I don't know what you mean by this. Lack of take-up, yes. Stability,
what's that?
Do you think we could do such standardisation for document fragments
and text fragments within the Media Fragments Group[3] ?
No. Disclaimer: I'm a MF WG member. Look at our charter [1] ...
Maybe this thread should slowly be moved over to [email protected] [2]?
Cheers,
Michael
[1] http://www.w3.org/2008/01/media-fragments-wg.html
[2] http://lists.w3.org/Archives/Public/uri/
--
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 16 Aug 2011, at 05:40, Sebastian Hellmann wrote:
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
