Re: [w3photo] RDF and ID's

On Sun, 8 Feb 2004, Greg Elin wrote:

> (I'm keeping this on the list because I think it is relevant to other
> RDF newbies...)
>
> On Sunday, February 8, 2004, at 01:26  PM, Libby Miller wrote:
>
> >
> > hi Greg
> >
> >> My questions:
> >> 1) Is it okay if used the format of placing an ID also inside the
> >> <image:hasPart> tag, e.g., <image:hasPart rdf:ID='hp1'> instead of, or
> >> in addition to, being inside the <image:Rectangle rdf:ID='p1'> tag?
> >> Does that form break it for other people?
> >>   <image:hasPart rdf:ID='hp1' >
> >>     <image:Rectangle rdf:ID='p1'>
> >
> > Unfortunately that breaks the RDF.
> >
> > RDF has objects and prooperties, which are usually syntactically
> > differentiated using a 'striped' syntax[1]. So you have
> >
> > foaf:Image (an object)
> >   image:width (a property)
> >   image:height (a property)
> >   image:hasPart (a property)
> >     image:Rectangle (an object)
>
> >
> > (notice also that by convention objects start with a capital letter).
> >
> > You can only have ids (and nodeIds, and rdf:resources and rdf:abouts)
> > referring to objects in RDF, never properties. So what's for you a
> > little syntactic difference breaks the RDF syntax, unfortunately.
>
> Why is the image:Rectangle an "object" and therefore can have an ID,
> but the image:hasPart is considered a property? Personally, I think of
> the part as being the object and the rectangle being a property of the
> part ("hasPart") just like image:width and image:height are properties
> of foaf:image object?

I guess it's a modelling question. Here we have said that the image has
a part and that part is a thing of type rectangle. which is reasonable,
I think. The 'hasPart property connects the Image and the Rectangular
part of the image.

>
> I mean we've talked about using rectangle or path, but if we are
> thinking recursively, wouldn't ultimately make more sense to say:
> foaf:Image (an object)
>       image:width (a property)
>       image:height (a property)
>       image:HasPart (an object)
>          HasPart: width (a property)
>          HasPart: height (a property)
>
I find that a bit confusing sorry, not sure what you're getting at.

> Or put another way, would we *ever* have an image:hasPart without
> having an image:Rectangle? From the vocab, if an image has a
> image:hasPart it must have an image:points.

You may be right, but that won't make a practical difference to our
syntax. In RDF you never have a property without an object at the end
of it as it were - you can't have a floating property that doesn't
point to anything. You could never be in the position of putting the id
on the xml tag nearest the literal text because it would always be a
property and never an object.

There are different syntaxes you could use for saying this in RDF: this
is one reason why using non-RDF xml tools to parse RDF is problematic.
Some of these syntaxes are probably simpler than this one. However this
one isn't really that complicated.

>
> As I'm thinking about this, I'm wondering if the little "syntactic
> difference" is the RDF saying hasPart is a property instead of
> image:rectangle. Seems to me the Part is the object that part of the
> whole image and the rectangle is the property that describes the Part.
>
> What is that says which of these two, hasPart and Rectangle is the
> property and which is the object?
>
> >>
> >> 2) What is the philosophy of putting the ID one level down and
> >> *inside*
> >> the tag has a property? What's the principle advantage? I think I'm
> >> open to following that form, but it seems to force a level of
> >> complexity on the parsing code (and hence the developer). Can I gain
> >> some insight?
> >>
> >
> > see above, I hope. Essentially it is difficult to represent a graph
> > structure using a heirarchical structure, and so you get some syntactic
> > oddities with RDF. A quick way to check if something will work is to
> > use
> > the RDF validator[2].
> >
> > In general, parsing RDF with XML is not a good idea....however I can't
> > oddhand find a php libbary for RDF parsing - Redland[3] can do it but
> > might be a bit heavyweight for your purposes.
>
> And there lies a significant hurdle for me...and, IMHO, a challenge
> that is being faced: that
> to adopt the strategy (e.g., RDF/semantic web) requires the use of
> heavy-weight tools.
>
> On hand, it goes without saying that eventually I could incorporate the
> full range of RDF
> into my code (and indeed would like to do so). On the other hand...it
> is proving non-trivial
> to incorporate this level of RDF quickly...and I worry about that
> fact's impact on facilitating
> adoption for others to follow in our path.
>

RDF does require a little extra work, but there are good tools to help
you use it.

> Perhaps there are other solutions? Perhaps someone could help me with
> my stumbling
> point. Perhaps I could just keep the data in a Fotonotes style and it
> would be easy to transform
> it to valid RDF in other repositories.

You could do that, and for example provide an xslt transform to RDF from
your version, as long as you take care to provide all the parts
required, and maintain the shape of the model that we decide on. RDF
makes explicit what's often implicit in XML vocabs, and it is this model
- currently [Image hasPart Rectangle] and the rest - is the important
part for interoperability.

Try running
http://swordfish.rdfweb.org/discovery/2004/01/w3photo-examples/paths-eg.rdf
through the validator http://www.w3.org/RDF/Validator/, showing the
graph rather than the triples, and see if it makes more sense like
that.

RDF 'knows' which are the objects and which are properties or
relations, and this facilitates using multiple namespaces and merging
documents together because this information is explicit rather than
just in the mind of the developer.

Libby

==================================
This is the TEMPORARY discussion list for the W3 Semantic-Photo History
Project. For questions, contact greg@fotonotes.net.

Subscribe Instructions
To:   semantic-photolist-request@unitboy.com
Body: subscribe

Unsubscribe Instructions
To:   semantic-photolist-request@unitboy.com
Body: unsubscribe

Help
To:   semantic-photolist-request@unitboy.com
Body: help

Received on Sunday, 8 February 2004 16:29:16 UTC