[Playlist] XSPF -> RDF - using GRDDL

[Daniel O'Connor]

> What's the right thing to do for an invalid input file?  If the date is
> misformatted, the version is "25", etc, what should the policy be?
>

Think of the current XSL and the way the it would be set up as: 'this
transformation is only designed for valid, schema compliant XSPF'. Sure, you
can misuse it and still get results; the same way you can use a brick to
build a house or hold open a door: one is the right use for the brick, the
other just happens to work (and works reasonably well).

If you use it on XSPF-like structures that make claims that they are XSPF
(use the namespace, are invalid); imo that is something that should be
covered off by the author and the use of a validator; and possibly the
community with a large stick.



> For example this testcase passes through the date, but shouldn't, since
> it's not XSD DateTime:
>
> FILE: ./data/other/for_version_1/fail/playlist-baddate.xspf
> <?xml version="1.0" encoding="utf-8"?>
> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:rdfs="http://www.w3.org/2000/02/rdfschema#" xmlns:play="http://xspf.
> org/ns/0/" xmlns:mo="http://purl.org/ontology/mo/"
> xmlns="http://xspf.org/ns/0/"
> xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dct="htt
> p://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/"
> xmlns:cc="http://web.resource.org/cc/" xmlns:owl="
> http://www.w3.org/2002/07
> /owl#">
>   <mo:MusicalItem rdf:about="">
>     <dc:created>2005-32-08T17:10:47-05:00</dc:created>
>   </mo:MusicalItem>
> </rdf:RDF>
>
> About mo:MusicalItem/dc:created, what's the formal definition of that
> field?  How is the date formatted?
>

Pretty sure it's ISO 8601, as per http://www.w3.org/TR/NOTE-datetime ; and
(luckily) that example just happens to be ISO 8601 :P



>
>
> For ./data/other/for_version_1/pass/playlist-extensive.xspf , the
> playlist title didn't get passed through.  This is probably a bug.
>


OOPS! How did I miss that.
Fixed in r693


>
> ...
>
> When the source playlist contains a //playlist/location but not a
> //playlist/identifier, you get this redundant fragment which is a bit
> sub-optimal:
>
>   <mo:MusicalItem rdf:about="http://example.com/">
>     <owl:sameAs rdf:resource="http://example.com/"/>
>

Odd; I can't quite reproduce it (Completely commented out
//playlist/identifier in playlist-extensive.xml)


>
> ...
>
> The paths in the output RDF for
> ./data/other/for_version_1/pass/playlist-xml-base.xspf
> need work.  This is a bug.
>
>
I'll have a tinker.


>
>
> A thought about tweaking the output: if the input XSPF file has a URI
> (as it will when this XSL is on the web), then that URI should pass
> through to mo:MusicalItem[@rdf:about].
>


Yup, that gets inferred by the consumer if we have  (rdf:about="" means this
document location)
mo:MusicalItem rdf:about=""


>
> ...
>
> In ./data/other/for_version_1/pass/track-extensive.xspf , I notice that
> the track duration doesn't pass through to the RDF.  That might be
> intentional (if there is no equivalent field in MO), but it might be an
> accident as well...
>

I couldn't find a nice mapping of duration at all.

>
> ...
>


Thanks for taking the time, I'll have a think about the xml:base issues and
also see if I can work out a neat way to avoid adding redundant owl:sameAs
content.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/playlist/attachments/20081015/3b4a5e15/attachment.htm