OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-metadata] Question about the IRI of a RDF subject from an ODFdocument


Svante.Schubert@Sun.COM wrote on 02/06/2007 07:57:32 AM:

> Hello Elias,
>
> I think I can speak for all that it is good to see you back on the list.
> Your technical experience is as welcome as needed as you just proved
> again. I am honestly happy to have you back in the SC.
> The usage of xml:base seems to be a very good idea.

Thank you.

>
> I am not sure, if this SC has to solve the following xml:base related
> problem, at least it plays into the area of #10 on our list "How do we
> cope with changes in content".

wow. That item definitely needs more thinking.

>
> I assume the base URL describes as well the document instance, which is
> usually described by no reference at all.
> Which means, if the RDF reference of the document instance is being
> changed, all relative references to resources in the document are being
> changed as well and by this their RDF references.
> Meaning that by changing the RDF subject of the document instance, all
> RDF subjects of the contained resources are being changed and are
> something completely new to RDF applications.
>
> Let me give an example:
> We use an ODF invoice template containing a certain imagine, which stays
> the same in all invoices.
> I assume that the base URL for the invoice document would change for
> every new invoice written.
> How would a RDF application is able to figure out that the images in the
> document are all the same, when the base URL and by this the image RDF
> reference is always different?
>
> Some might say a possible solution could be to change the base URL with
> every save of the document, by this we would be sure to talk about a new
> instance. We could use an owl:sameAs to the first URI used by the
> template or the URI of the first occurrence of the resource in the
document.
> On the other hand in the end the user has to define, when the resource
> is being changed in a way that it is no longer correct to give an
> owl:sameAs.

Right. It's definitely complicated.

>
> My sincere condolences for your loss, Elias.

Thank you.

>
> Regards,
> Svante
>
> Elias Torres wrote:
> > Hello everyone,
> >
> > I'm slowly starting to get back to work, after a long hiatus, but not
only
> > because of my vacation but due to a death in the family and an
additional
> > personal accident I had. I hope things have progressed while I was gone
and
> > that there's still ways in which I can offer some help to the group.
Let me
> > try for example to suggest some things on the subject of this email.
Please
> > forgive me if I repeat some suggestion stated before and whether it was
> > already made clear that what I'm suggesting either doesn't apply or the
> > group decided it was not the right solution. I acknowledge I am not
fully
> > up to date with all of the discussions that have been going on during
my
> > absence.
> >
> > -Elias
> >
> > Svante.Schubert@Sun.COM wrote on 02/05/2007 03:10:55 PM:
> >
> >
> >> Bruce D'Arcus wrote:
> >>
> >>> On Jan 30, 2007, at 1:51 PM, Bruce D'Arcus wrote:
> >>>
> >>>
> >>>> This is a trick issue, BTW. Ideally you want a globally unique IRI
> >>>>
> >
> > Definitely a tricky situation. But one that needs to be addressed.
First, I
> > don't think that there is a simple solution (e.g. an almighty IRI that
will
> > solve all of the problems). In my opinion, it's just a matter of
providing
> > enough metadata to describe whatever it is that we are trying to
> > communicate/document.
> >
> >
> >>>> with which you can also locate the document. But that's not
realistic
> >>>> in many desktop scenarios, so I think you're left with two choices:
> >>>>
> >>>> 1) the one above
> >>>> 2) using a URI-encoded UUID
> >>>>
> >>> Well, and of course using the Flickr URI, which would be good for
this
> >>> particular case.
> >>>
> >> By this we have at least one case where the RDF subject IRI is not the
> >> reference to the local instance.
> >> As we use the flickr URL as the RDF subject IRI, we are in need of a
way
> >> to reference to the image from our RDF syntax.
> >> Only by this, the RDF application would know, that we are talking
about
> >> a picture in this document.
> >> BTW a similar reference would be needed for linking to other ODF
> >> elements, for instance if we would like to reference to a certain ODF
> >> table or the linked image, that is being used in the document.
> >>
> >> My question to you now, is it from the RDF point of view  sufficient
to
> >> say, we have this picture somewhere in this document?
> >>
> >> In N3 something like:
> >> <> has <http://www.flickr.com/photos/images/holidayimage.png> .
> >>
> >> Or are we in need of a package URL to the described content?
> >>
> >> In N3 something like:
> >> @prefix odf: <http://www.oasis-open.org/package-rdf#>
> >> <http://www.flickr.com/photos/images/holidayimage.png> odf:pack-ref
> >> <odf:/images/holidayimage.png>
> >>
> >> (A package URL  as relative URI references are not allowed in RDF URI
> >> References [1] )
> >>
> >
> > You can't use a relative URI in a triple at the model level, but you
can
> > use a relative URI in the serialization of triples.
> >
> > In a document located at /home/eliast/package.n3 you can have the
> > following:
> >
> > <eliast.jpg> dc:title "Elias' mugshot" .
> >
> > When the document is loaded eliast.jpg would be resolved to the URI:
> > "file:///home/eliast/eliast.jpg".
> >
> > However, we need more than that, because our package doesn't have a
stable
> > location. Hence, I would suggest we ground it on some URN, like LSID
for
> > example or whatever.
> >
> > urn:lsid:www.oasis-open.org:SOME_PACKAGE:SOME_UUID/eliast.jpg
> >
> > Now if we use RDF/XML we can make use of
> > xml:base="urn:lsid:www.oasis-open.org:SOME_PACKAGE:SOME_UUID/".
> >
> > <eliast.jpg> dc:title "Elias' mugshot" .
> >
> > For the case that the same exact picture lived on Flickr, then we can
use
> > owl:sameAs:
> >
> > <eliast.jpg> owl:sameAs
> > <http://www.flickr.com/photos/images/holidayimage.png> .
> >
> > N3 doesn't have an @base property like SPARQL or RDF/XML, but Turtle
which
> > is updated by the SWIG, is in the process of adding such extension.
> >
> >
> >>> Might be nice if we could add the ability to have both a path and a
> >>> global IRI in the manifest entry for a file.
> >>>
> >>>
> >> [1]  Note: Relative URI references are not allowed in RDF URI
References:
> >> "RDF URI references are compatible with the anyURI
> >> <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#anyURI> datatype
as
> >> defined by XML schema datatypes [XML-SCHEMA2
> >> <http://www.w3.org/TR/rdf-concepts/#ref-xml-schema2>], constrained to
be
> >> an absolute rather than a relative URI reference.", taken from
> >> http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
> >>
> >>
> >
> >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]